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PREFACE 


Since Intel introduced the iSBC 80/10 aGinalé Board Computer in early 1976, the family of Intel OEM 
Microcomputer Systems has grown rapidly. Original equipment manufacturers and volume end-users 
alike have responded to the concept originated by Intel of having all the functions of a computer — cen- 
tral processing unit, memory, input-output and system expansion capability — present on one printed Cir- 
cuit board. 


The capabilities of a single board computer have been enhanced by the creation of the ndustw-Siandard 
MULTIBUS system bus. System expansion boards have been introduced for memory, serial I/O and 
parallel 1/O expansion, as well as analog I/O, DMA controllers and peripheral controllers. A unique feature 
of the MULTIBUS architecture, however, is its capability to support multiple single board computers. This 
capability permits sophisticated multiprocessing configurations using standard off-the-shelf 8-bit and 
16-bit single board computers. The introduction of the iSBX MULTIMODULE expansion boards has revolu- 
tionized the concept of the single board computer. Now iSBC host boards may be custom configured with 
iSBX expansion boards based on the I/O requirements of the application. This capability provides lower 
cost, higher performance single board solutions. Powerful software tools like the iRMX 80 and iRMX 88 
Real-Time Executives and the iRMX 86 Operating System are key members of the iSBC product family. 
They provide users with the tools for quick implementations of simple or complex systems. iCS product 
line provides chassis and signal conditioning/termination strips as well as board level products which 
were developed specifically for industrial users. 


This application manual is divided into three sections: iSBC Hardware, iSBC Software and iCS Products. 
It contains all of the current application notes, reliability reports, magazine articles and professional jour- 
nal reprints on the products of the Intel iSBC product family. We have compiled all of this information into 
a single publication for your convenience. Please contact us with your questions, comments, and sugges- 
tions on how we may provide you with useful information on our products. 


INTEL CORPORATION 

OEM Microcomputer Systems 
Applications Engineering | 
Hillsboro, Oregon 97123 — 
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INTRODUCTION 


The recent entry of the single board computer into 
the broad field of electronic applications is sub- 
stantiating the billing as a “super component”’. 
Single board computers provide a solution to 
several problems that have not been solved by the 
use of conventional computers: cost, size, and 
design specialization. 


Many potential microcomputer applications have 
been overlooked because of the design tasks 
required to build a microcomputer system. These 
tasks traditionally include interfacing of the system 
clock, read/write memory, I/O ports and drivers, 
serial communications interface, bus control logic 
and drivers. Intel’s iSBC 80/10A enables the design 
engineer to concentrate on the application of 
microcomputers, rather than on implementation 
details. 


This application note begins with an overview of 
the Intel® iSBC 80/10A. Readers who are familiar 
with the iSBC 80/10A may choose to skip to the 
applications section, which describes the following 
typical iSBC 80/10A applications: 
@ The iSBC 80/10A used for instrumentation 
control of a Fluke 8375 Digital Multimeter. 
e The iSBC 80/10A used as a SCADA Terminal 
- in a communication application. | 
@ The iSBC 80/10A used for temperature moni- 
toring in a process control application. 


e The iSBC 80/10A used as an interrupt driven 
device controller for a Centronics printer. 


RS 232C 
COMPATIBLE 
DEVICE 


CONTROL 
INTERFACE 


CONTROL 
INTERFACE 


DATA 
: INTER- 
VAN FACE 
RS 232C 
INTERFACE 


PROGRAMMABLE 
COMMUNICATIONS 
INTERFACE 

. (USART) 


2 INTERRUPT 
REQUEST 


SELECTABLE 
; LINES 


8K x 8 
ROM/PROM 

MEMORY _ 
(SOCKETS) 


BUS INTERRUPT 
REQUEST LINE 


INTERRUPT | 


Each example shows the user program and hard- 
ware required for the application. The program 
listings are interspersed with the text describing 
the application. Both 8080 Macro Assembly 
Language and Intel’s PL/M-80 are used in the 
examples. 


The software was developed on an Intel® Micro- 
computer Development System (MDS). The MDS 
provided the tools necessary to edit, assemble or 
compile, link and locate the application software. 
Hardware development was facilitated by the use 
of Intel’s In-Circuit Emulator (ICE 80). For further 
information regarding the Microcomputer Develop- 
ment System, the reader is referred to the publica- 
tions listed at the beginning of this application 
note. | 


OVERVIEW 


The iSBC 80/10A is a member of Intel’s complete 
line of OEM computer systems which take full 
advantage of Intel’s LSI technology to provide 
economical, self-contained computer based solu- 
tions for OEM applications. The iSBC 80/10A is a 
complete computer system on a single 6.75-by-12 
inch printed circuit card. A block diagram of the 
iSBC 80/10A is shown in Figure 1. 


Intel’s powerful 8-bit n-channel MOS 8080A CPU, 
fabricated on a single LSI chip, is the central pro- 
cessor for the iSBC 80/10A. The 8080A contains 
six 8-bit general purpose registers and an accumu- 
lator. The six general purpose registers may be 
addressed individually or in pairs, providing both 
single and double precision operators. 


USER DESIGNATED 
PERIPHERALS 


PARALLEL I/O LINES 


1 I ae PROGRAMMABLE 


REQUEST 


DRIVER/TERMINATOR 
INTERFACE 


PROGRAMMABLE 
PERIPHERAL 
INTERFACE 


SBC-80/10A 
SYSTEM 


BUS MEMORY 
| AND 
1/0 
VV EXPANSION 


1. Interrupts originating from the Programmable Communications Interface and Programmable Peripheral Interface are jumper seiectable. 


Figure 1. iSBC 80/10A Block Diagram 
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The 8080A has a 16-bit program counter which 
allows direct addressing of up to 64K bytes of 
memory..An external stack; located within .any 
portion of read/write memory, may be used as a 
last in/first out stack to store the contents of the 


program counter, flags, accumulator and all of the 


six general purpose registers. A 16-bit stack pointer 
addresses the external stack. This provides sub- 


routine nesting that is bounded only by memory 


size. 


The iSBC .80/10A contains 1K bytes of. read/ 


write memory using Intel’s low power static RAM. 


All on board RAM read and write operations are 


performed at. maximum processor speed. Four 


sockets for up to 8K bytes of non-volatile read-: 


only memory are provided on the board. Read- 
only memory may be added in 1K byte increments 
(up to 4K total) using Intel® 8708 erasable and 
electrically reprogrammable ROMs (EPROMs) 
or Intel 8308 masked ROMs. Optionally, if more 
than 4K bytes are required, read only memory may 
be added in 2K byte increments (up to 8K total) 
using Intel® 2716 EPROMs or 2316E masked 
ROMs. All on-board ROM or EPROM read opera- 
tions are performed at maximum processor speed. 


The iSBC 80/10A contains 48 programmable para- 
llel I/O lines implemented using two Intel® 8255 


Programmable Peripheral Interfaces. The system. 


software is used to configure the I/O lines in any 


combination of unidirectional input/output, and © 
bidirectional ports indicated in Table I. Therefore, 


the I/O interface may be customized to meet 
specific peripheral requirements. To support the 
large number of possible I/O configurations, 
sockets are provided for interchangeable I/O line 
drivers and terminators. Hence, the I/O interface 


provides the appropriate combination of optional 
line drivers and terminators to allow the required 
sink current, polarity, and drive/termination 
characteristics for each application. The 48 pro-. 
grammable I/O lines and signal ground lines are 
brought out to two 50-pin edge connectors that 
mate with flat, round, or. woven cable. ' 


A programmable communications interface using 
Intel’s 8251 Universal Synchronous/Asynchronous 
Receiver/Transmitter (USART) is contained on the 
iSBC 80/10A. A jumper selectable baud. rate 
generator provides the 8251 with all common 
communication frequencies. The 8251 can be pro-. 
grammed by the user’s system software to select 
the desired asynchronous or synchronous serial 
data transmission technique (including IBM Bi- 
sync). The mode of operation (synchronous or 
asynchronous), data format, control character 
format, parity, and asynchronous transmission 
rate are all under program control. The 8251 pro- 
vides full duplex, double buffered transmission and 
receive capability. Parity, overrun, and framing 
error detection circuits are all incorporated in the 
8251. The inclusion of jumper selectable TTY or 
EIA RS232C compatible interfaces on the board, 
in conjunction with the 8251, provide a direct 
interface to. teletypes, CRTs, asynchronous and 
synchronous modems, and other RS232C com- 
patible devices. The RS232C or TTY command 
lines, serial data lines, and signal ground lines are 
brought out to a 25-pin edge connector that mates 
with RS232C compatible flat, round, or woven 
cable. oe i ge ke” ? Bete 


Interrupt requests may originate from six sources. 
Two from the 8255’s, two from the 8251 and two 
from user designated peripheral devices. 


TABLE 1 INPUT/OUTPUT PORT MODES OF OPERATION 


_IN 
UNLATCHED 
X 


X 


MODE OF OPERATION _ 


UNIDIRECTIONAL 


ee ae OUTPUT 
i ~ | LATCHED & 
) | LATCHED | STROBED 
X | X 


ae ee ae ee ee 


1. Note: Port 3 must be used as a control port when either Port 1 or Port 


strobed output or Port 1 is used as a bidirectional port. 
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2 are used as a latched and strobed input or a latched and 
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The 8255’s can generate interrupts when 4 byte of 
information is ready to be transferred to the CPU 
(i.e., input buffer full) or a byte of information has 
been transferred to a peripheral device (i.e. , output 
buffer is empty). 


The 8251 can generate interrupts when a character 
is ready to be transferred to the CPU (i.e:, receive 
channel buffer is full) or a character is ready to be 
transmitted (1.e., transmit channel data buffer is 
empty). , , - 
The user designated peripheral devices can generate 
two interrupts: one via the system bus and the 
other via the I/O edge connector. 


The two interrupts from the 8255’s and the two 


interrupts from the 8251 are all individually mask- 
able under program control. The six interrupt 
request lines share a single CPU interrupt level. 
When an interrupt request is recognized, a RE- 
START 7 instruction is generated. The processor 
responds by suspending program execution and 
making a subroutine call to a user defined interrupt 
service routine originating at location 38 (Hexa- 
decimal). | 


iSBC 80/10A memory and I/O capacity may be 
increased by adding standard Intel memory and 
I/O boards. Modular expandable backplanes and 
card cages, each with a four-board capacity, are 
available to support multi-board systems. 


The development cycle of iSBC 80/10A eased 
products may be significantly reduced using the 
Intellec Microcomputer Development System. The 
resident macro-assembler, PL/M-80 compiler, text 
editor, and system monitor greatly simplify the 
design, development, and debug of user designed 
iSBC 80/10A system software. A diskette-based 
system allows programs to be loaded, assembled, 
edited, and executed faster than using Sonventional 
paper tape, card, or cassette peripherals. A unique 
In-Circuit Emulator (ICE 80) provides the capa- 
bility of developing and SeDUaEHIE software 
directly on the iSBC 80/10A. 


iSBC CONFIGURATION OPTIONS 


The iSBC 80/10 provides the user with a sowerful 
and flexible I/O capability for both parallel and 
serial transfers. This section discusses the user 
programmable and jumper-selectable options, and 
bus interfacing. 


SERIAL I/O OPTIONS ~ 

The serial I/O interface, using Intel’s 8251 USART, 
provides a serial data communications channel that 
can be programmed to operate with most of the 
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current serial data transmission protocols. There 
are three general areas of serial I/O options: 


1. choice of interface type, RS232C or current 
loop, 


2. baud rate and. program- selectable mode 
-. options, : 


3. choice of an interrupt mechanism. 


The user has the choice, through jumper connec- 
tions, of configuring the serial I/O logic to present 
either an RS232C or a 20 mA current loop inter- 
face to an external device. If an RS232C interface 
is used, the 8251 can assume the role of a “data 
set’? or a ‘“‘data processing terminal’’. This enables 
the serial interface to be connected to different 
devices such as modems and computer terminals. 


There are two factors which enter into the choice 
of baud rate. They are the actual clock frequency 
used to drive the transmit/receive clocks on the 
8251 and the baud rate factor selected by a pro- 
grammable mode instruction control word output 
by the processor to the 8251. The baud rate factor 
is used to effectively divide the 8251 transmit and 
receive clocks by 1, 16 or 64. During normal oper- 
ation a factor of 16 is selected for asynchronous 
transmissions from 9.6K to 300 baud. A factor of 
64 must be used to achieve a baud rate of 110. The 
baud rate factor is only applicable to asynchronous 
transmission, as all synchronous transmission is 
done with an implied factor of one. 


Before beginning serial I/O operations, the 8251 
must be program-initialized to support the desired 
mode of operation. The CPU initializes the 8251 
by issuing a set of control bytes to the ara 
device. These control words specify: | 


e ‘synchronous or asynchronous Operation | 
baud rate factor 

character length 

number of stop bits 

even/odd parity | 

parity/no parity 


Refer to the iSBC 80/10 and iSBC 80/10A Single 
Board Computer Hardware Reference Manual or 
the “8251 Application Note” for details on the 
control words used to direct the operation of the 
8251. 


The serial I/O logic can be configured with differ- 
ent forms of interrupt request mechanisms. By 
connecting a jumper, the user can allow the 8251’s 
Receiver Ready output to generate an interrupt 
request. The Receiver Ready output goes high 
whenever the Receiver Enable bit of the command 
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word has been set and the 8251 contains a charac- 
ter that is ready to be input to the CPU. The user 
can also choose to have the 8251’s Transmitter 
Ready or Transmitter Empty output activate the 
interrupt request. The Transmitter Empty goes 
high when the 8251 has no characters to transmit. 
Transmitter Ready is high when the 8251 is ready 
to accept a character from the CPU. Both Trans- 
mitter Empty and Transmitter Ready are enabled 
by setting the Transmit Enable bit of the command 
word. Upon receiving an interrupt, the program 
can determine the actual condition which is 
responsible for the interrupt by reading the status 
of the 8251 device. 


PARALLEL I/O OPTIONS 


The parallel I/O interface consists of six 8-bit I/O 
ports implemented with two Intel 8255 Program- 
mable Peripheral Interface devices. Eight lines 
already have a bidirectional driver and termination 
network permanently installed. The remaining 40 
lines are uncommitted. Sockets are provided for 
the installation of active driver networks or passive 
termination networks as required to meet the 
specific needs of the user system. | | 


The primary considerations in determining how to 


use each of the six I/O ports are:. | 
1. choice of operating mode, 


2d. 
bidirectional), 


3. selection of interrupt mechanism, 


4. choice of driver/termination wos for 
the port’s data path. 


Operating Modes. There are three basic operating 
modes that can be selected by the system software. 
The modes of operation will be described here in 
general terms, leaving it to the reader to obtain 
details from the iSBC 80/10 and iSBC 80/10A 
Single Board Computer Hardware Reference 
Manual or the “8255 Application Note.” 


Mode 0 is a basic input/output functional con- 
figuration which provides simple input and out- 
put operations. No “handshaking” is required, 

data is simply written to or read from a specified 
port. The outputs are latched and the inputs are 
unlatched. 


Mode 1 is a strobed input/output functional 
configuration which provides a means for trans- 
ferring I/O data to or from a specified port in 
conjunction with strobes or handshaking signals. 


The outputs are latched and are accompanied by 


direction of data flow (input, output or 
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an output control line which indicates that the 
processor has loaded the output port with a data 
byte. The input data is latched when accompa- 
nied by its externally operated control signal. 


Mode 2 is a strobed bidirectional. bus input/ 
output functional configuration which provides 
a means for communicating with a peripheral 
device or structure on a single 8-bit bus for both 
transmitting and receiving data. Handshaking 
signals are provided to maintain proper bus flow 
discipline in a manner similar to mode 1. 
Data Flow Direction. In addition to the choice of 
operating mode, the user may also specify the 
direction of data flow, input or output from the 
8255’s. At the time of RESET, the 8255’s are 
configured into the input mode until altered by a 
control word directed to the control word register. 
When an output mode control word is received, 
all of the data’ bits are set to the low output state. 


Interrupt. Mechanism. When the 8255 is pro- 
grammed to operate in mode | or mode 2, control 
signals are. provided that can be used as interrupt 
request inputs to the CPU. The interrupt request 
signals, generated from one of the ports (port C), 
can be inhibited or enabled by setting or resetting 
the associated interrupt enable flip-flop, using the 
bit set/reset function of port C. This function 
allows the programmer to mask the interrupts from 
specific I/O devices without affecting any other 
device i in the interrupt structure. . 


Driver[Termination Networks. Depending on the 
direction of data flow, the user will select the 
appropriate TTL line drivers and Intel terminators 
that are compatible with the I/O driver/terminator 
sockets on the iSBC 80/ 10A. The list of suitable 
line drivers includes those with inverting, non- 
inverting, and open collector characteristics. 
There are two types of terminators: a 220-ohm/ 
330-ohm divider or a 1K ohm pull-up. 


BUS INTERFACING 


The system bus interface logic consists of three 
general groups of circuitry: | 


1. gates that accept. the various bus control 
signals, the interrupt request lines, and the 
ready indications, and then apply. these 
signals to the CPU logic elements, | 


the system bus drivers, 


3. the failsafe circuitry which generates | an 
| acknowledgment during interrupt sequences 
and during those cycles in which an ac- 
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knowledgment is not returned because a 
non-existent device was inadvertently ad- 
dressed. 


Bus Interface Signals. The following paragraphs 
describe portions of the system bus interfacing 
logic relevant to interfacing a user device to the 
iSBC 80/10A. (Note: Whenever a signal is active- 
low, its mnemonic is followed by a slash; for 
example, MRDC/ means that the level on that line 
will be low when the memory read command 
is true.) 


BCLK/ — Bus clock; used to synchronize bus 
control circuits on all master modules. BCLK/ 
has a frequency of 9.216 MHz. BCLK/ may 
be slowed, stopped or single stepped, if 
desired. 


INIT/ — Initialization signal; resets the entire 
system to a known internal state. 


BPRN — Bus priority input signal; indicates to 
the iSBC 80/10A that a higher priority mas- 
ter module is requesting use of the system 
bus. BPRN suspends the processing activity 
and drivers of the iSBC 80/10A until the sig- 
nal goes low. 


BUSY/ — Bus busy signal; indicates that the bus 
is currently in use. BUSY/ prevents all other 
master modules from gaining control of the 

~ bus. BUSY/ is driven by the HLDA/ output 
from the iSBC 80/10A in response to a 
BPRN input. It indicates that the bus is 
available. - | 7 

MRDC/ — Memory read command; indicates 
that the address of a memory location has 
‘been placed on the system address lines and 


specifies that the contents of the addressed 


location are to be read and placed on the sys- 
tem data bus. 


MWTC/ — Memory write command; indicates 
that the address of a memory location has 
been placed on the system address lines and 
that a data word has been placed on the 
system data bus. MWTC/ specifies that the 
data word is to be written into the addressed 
memory location. 


IORC/. — I/O read command; indicates that the 


address of an input port has been placed on 
the system address bus and that the data at 
that input port is to be read and placed on the 
system data bus. 


IOWC/ — I/O write command; indicates that the 
address of an output port has been placed on 
the system address bus and that the contents 
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of the system data bus are to be output to 
the addressed port. 


XACK/ — Transfer acknowledge signal; the 
required response of an external memory 
location or I/O port which indicates that the 
specified read/write operation has been com- 
pleted (that is, data has been placed on, or 
accepted from, the system data bus lines). 


AACK/ — An advance acknowledge, in response 
to a memory read or write command, that 
allows the memory to complete the specified 
operation without requirifg the CPU to wait. 


CCLK/ — Constant clock; provides a clock signal 
of constant frequency (9.216 MHz) for use by 
optional memory and I/O expansion boards. 
The same signal is used to drive both CCLK/ 


and BCLK/. 
INTRI/ — Externally generated interrupt re- 
quest. 


ADRO/—ADRF/ — 16 Address lines; used to 
transmit the address of the memory location 
or I/O port to be accessed. ADRF/ is the most 
significant bit. 


DATO/—DAT7/ — Bidirectional data lines; used 
to transmit/receive information to/from a 
memory location or I/O port. DAT7/ is the 
most significant bit. 


Bus Acknowledges. Further distinction between 
transfer acknowledge (XACK/) and _ advance 
acknowledge (AACK/) is required. All external 
memory and I/O transfer requests must return 
XACK/ to the iSBC 80/10A (even if AACK/ is also 
returned). XACK/ indicates that data has been 
placed on (read command) or accepted from (write 
command) the system data bus lines. AACK/ is an 
advance acknowledge in response to a memory or 
I/O port command. It has been provided because | 
the 8080A samples the ready line before valid data 
is required on the bus. If this condition is properly 
anticipated, AACK/ can be returned before the 
data is actually read, thus allowing an earlier opera- 
tion to be completed. AACK/ should be used only 
with a thorough understanding of the additional 
information provided in the iSBC 80/10 and 
iSBC 80/10A Single Board Computer Hardware 
Reference Manual. DMA Transfers. An external 
device can make DMA transfers. to or from RAM 
expansion boards. The transfer is coordinated 
with the iSBC 80/10A by means of two bus 
signals: bus priority input (BPRN) and: bus busy 
(BUSY/). The first step in making a.DMA transfer 
is to obtain control of the system bus. This is 
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achieved by asserting BRPN to the iSBC 80/10A 
and then waiting until the iSBC 80/10A returns 
BUSY/, indicating that it has relinquished control 
of the system bus. When this step is completed the 
external device may proceed with its DMA trans- 
fers until it is finished. At that time BPRN should 
be removed to allow the iSBC 80/10A to regain 
control of the system bus. It should be noted 
that the iSBC 80/10A is placed in a hold state 


bus. 


APPLICATIONS 


The iSBC 80/10A may be applied: to a wide eae 
of applications. Specific applications in four areas 
are presented in this application note. They are 
presented to illustrate a broad spectrum of single 
board computer capabilities and to demonstrate 
the use of various system features. 


INSTRUMENTATION » 

Microprocessors have been used in instrumentation 
for many tasks ranging from handling simple inter- 
face functions to control of the analog to digital 
conversion process. The use of a single board com- 
puter can’ further serve in the application of 
instruments themselves to: laboratory or process 
control environments. It is quite often necessary in 


these applications to control instrumentation. 


remotely. A number of rather expensive minicom- 
puter-controlled solutions now exist on the market 


as automatic test equipment (ATE) systems. The. 
iSBC 80/10A presents itself as a cost effective solu-. 


tion in situations where the larger ATE systems are 
beyond economic justification. | 


The iSBC 80/10A can be the sole CPU. si enn 


in the system, providing instrumentation: control 
and .computational capability; or it.can supple- 


ment a larger host CPU by: nasgune distributed > 


Processes posure ments: 


instanienaten Control. ‘Aopticauon Bangle. 

Most instruments such as DVMs, counters,- data 
loggers, synthesizers, ‘etc., have optional data out- 
put. units: (DOUs) and/or remote control units 


(RCUs): It is particularly time consuming to inter-. 


face each instrument’s DOU/RCU: with custom- 
digital logic. Until the recent IEEE-488 interface 
standard, there was. little in common from one 
interface to the next. The parallel I/O lines of the 
iSBC 80/10A provide a common interface element 


that can be adapted to a majority of the DOUs and 


RCUs available today by means of software. 


when it does not have control of the. system. 


». FLUKE 8375 


DOU iSBC 80/10A .. 


. PORT 4 (A). 


DIGIT 


SELECT | 


CONTROL ., 


GROUP #2 
8255 


Figure 2. Interface Block'Diagram © 


This instrumentation: control.,application shows 
how the iSBC 80/10A has been. used to control and 
read the data from the data output unit (DOU) of 
a Fluke 8375 Digital Multimeter. . 


Interfacing the iSBC 80/10A ‘to the Fluke 8375 
DOU has been accomplished through the use of 
three parallel I/O ports shown in Figure 2. An 8-bit 
port has been used to read input data from the 
Fluke 8375 DOU. Another 8-bit port has. been 
used to control the multiplexing of data: from the 
DOU to the iSBC 80/10A. And, an 8-bit port has 
been used to provide the required control, and 
monitoring of the following DOU | functions: 
busy flag, sample sync flag, timeout enable, exter- 
nal trigger and trigger inhibit. 

The. following listing contains a gomplete program 
to provide the necessary interface. control func- 
tions as well as an exercise program. The program 
listing is interspersed with text that is used to 
clarify the elements of ile PIoevam. 


INSTRUMENTATION CONTROL APPLICATION 
“FLUKE 8375 DIGITAL MULTIMETER ; 
DATA OUTPUT UNIT (DOU) CONTROLLER’: 


DWAAMN HWwWh - Oo 


The CSEG directs the ISIS-II 8080 Assembler to 
generate a relocatable code segment. Relocatable 
code can later be placed at any memory address by 
Intel’s LOCATE program. This lets you write your 
program without worrying about the application’ S 
final memory configuration. | 


WwW CSEG 
; eG 
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Equate Table. The following table is used to give 
symbolic names to the binary I/O port addresses. 
The names used later in the program increase 
readability. 


; 
. 16; EQUATE TABLE 


7 3 
18 CWR EQU OEBH ; 8255 #2. CONTROL WORD REGISTER 
19 DATIN EQU OE8H ; DECADE PAIR DATA INPUT PORT 
20 STB EQU . OE9H ; STROBE OUTPUT PORT 
21 FLG EQU OEAH ; FLAG INPUT PORT 

TRG EQU OEAH 3 TRIGGER OUTPUT PORT 


The exercise program uses some of the subroutines 
provided in the iSBC 80/10A System Monitor 
PROMs. The addresses of the subroutines are 
included in the equate table. 


25 

26 ; 

27 GETCH EQU 
28 CO EQU 
EQU 
EQU 


0220H 
01E8H 
O1F3H 
02C2H 


; GET CONSOLE INPUT, MASK OFF PARITY 
; CONSOLE OUTPUT 

; PRINT <CR><LF> 

; DISPLAY BYTE IN ACCUM 


29 CROUT 
30 NMOUT 
31 5 

32 


The use of the iSBC 80/10A parallel I/O ports 
requires that the mode of operation be defined for 
each port. This is typically done by an initializa- 
tion subroutine executed when the iSBC 80/10A 
is powered up or reset. 


8255 Control Word. When the opcode field (bit 7) 
of a control word directed to an 8255 is equal to 
one, the control word is interpreted as a mode 
definition control word. The mode definition 
control word format is shown below: 


CONTROL WORD 


[27] 6} P5[ 24] Os |>2 [Or | Po 
a GROUP B 


PORT C (LOWER — PC3-PCo) 
1 = INPUT 
0 = OUTPUT 


PORT B 
1 = INPUT 
0 = OUTPUT 


MODE SELECTION. 
0 = MODE 0 
1= MODE 1 


— GROoUPA . XO 


PORT C (UPPER ~PC7—PCy) 
1 = INPUT 
0 = OUTPUT 


PORT A 
1=iNPUT 
0 = OUTPUT 


MODE SELECTION 
00 = MODE 0 
01=MODE 1 
1X = MODE 2 


OPCODE 


1 = MODE SET 


Observing the schematic for the iSBC 80/10A — 


Fluke 8375 DOU (Figure 3), it can be seen that the 
8255 #2 should be configured through the use of 
the mode control word as: 


Port 4(A) Mode 0O Input 


Port 5(B) ModeQO Output 
Port 6(C) Bits PC2—PCO Output 
Port 6(C) Bits PCS5—PC4 Input 


The following mode control word is used: 


Port C Bits PCg—PC2 Output = 0 


Port B Output = 0 


Port B Mode 0 = 0 


Port C Bits PC4—PCs5 Input = 1 


Port A Input = 1 


Port A Mode = 00 


Opcode Mode Set = 1 


Mode Control Word = 1001 1000 Binary = 98H 


34; 

35 3 *#* 8255 #2 INITIALIZATION SUBROUTINE 

36 ; 

37 INIT . 

38 MVI A, 100110008 _; LD MODE CONTROL WORD 


CWR ; OUTPUT TO 8255#2 CNTL WD REG 


This coding loads the mode control word into the 
8255 #2 control word register. Additional initial- 
ization code is required to set the strobe and 
trigger output ports to an inactive state. The sche- 
matic shows that inverting drivers have been used 
for both the strobes and the trigger. When a com- 
mand is issued to place port 5 (B) into the output 
mode, bits PB7—PBO are set to the low output 
state. Because the low outputs are then inverted 
and used as strobes to the Fluke 8375, they must 
then be disabled. The initialization subroutine 
concludes by disabling the strobes and trigger. The 
strobes are signals to the DOU which enable its 
drivers to send data to the iSBC 80/10A. The trig- 
ger is a signal to the DOU that the Fluke 8375 
should take a reading. 


A, OFFH 
STB 
TRG 


; LD MASK TO: 
DISABLE STROBES 
; . DISABLE TRIGGER 


External Trigger Control. Two subroutines are 
implemented to enable and disable the external 
trigger mode of the instrument. These subroutines 
use the bit set/reset capability of the 8255 to inde- 
pendently set or reset three control lines of the 
Fluke 8375 DOU. 
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When the opcode field (bit 7) of an 8255 control 
word equals zero, the control word is a port 6 (C) 
bit set/reset command word. 


The bit set/reset control word format is shown 
below: | 


CONTROL woRD 


0 = RESET BIT 
1= SET BIT 


D3 D2 Dy PORT C BIT 


NOT USED SET TO 000 


—rw 2B OOOO 
—-~s OO] 00 
-O- 0-0-0 


OP CODE 
0 = BIT SET/RESET 


The following example demonstrates how the port 
6 (C) bit set/reset control word is constructed to 
disable the Fluke 8375 external trigger. Note from 
the schematic (Figure 3) that port 6 (C) bit 0 con- 
trols the inhibit external trigger line. — 


Set Bit = 1 


Bit Select = 000 (Binary) 


Not Used = 000 (Binary) 


Bit Set/Reset Opcode = 0 


The control word for set Port C bit 0 is 0000 0001 Binary = 01H 


50 

51; 

52 ; **#* ENABLE EXTERNAL TRIGGER SUBROUTINE ### 

53 3 

54 ETRIG: 

55 MVI A, 000000008 ; LD RESET BIT 0 CONTROL WORD 
56 OUT CWR 3 OUTPUT TO 8255#2 CNTL WD REG 
57 RET 


58 ; 
59 ; *** DISABLE EXTERNAL TRIGGER SUBROUTINE ### 
60 3 


’ 
61 DTRIG: 
62 MVI A,00000001B 3 LD SET BIT 0 CONTROL. WORD 
63 OUT CWR ; OUTPUT TO 8255#2 CNTL WD REG 
64 RET 
65 ; 
66 


Subroutines to enable and disable the timeouts are 
written in an analogous fashion. The timeout 
enable line is controlled by port 6 (C) bit 2. 


67 

68 ; 

69 ; ##*# ENABLE TIMEOUTS SUBROUTINE *##* 

70 ; 

71 EPOS: 

T2 MVI A,00000101B ; LD SET BIT 2 CONTROL WORD 
73 OUT - CWR ; OUTPUT TO 8255#2 CNTL WD REG 
74 RET 

15 5 

76 ; ##* DISABLE TIMEOUTS SUBROUTINE #*# 

TT 3 

78 DPOS: 


719 ~ MVI A,00000100B 3; LD RESET BIT 2 CONTROL WORD, 
80 OUT CWR ; OUTPUT TO 8255#2 CNTL WD REG 
81 ~ RET : “s 
82 ; 

83 


Obtaining Readings. The Fluke 8375 DOU allows 
readings to be taken in one of two modes. The 
first, a triggered mode, assumes that the external 
triggering has not been inhibited and requires the 
positive edge of a pulse with a minimum width of 
1 microsecond on the trigger input. Setting and 
resetting the port 6 (C) bit 1 produces the 8375 
external trigger. After a reading is triggered the 
8375 busy flag is tested until the not busy state is 
reached. At that time the reading that was 
triggered can be read by the iSBC 80/10A. The 
last statement in this routine jumps to TKDATA 
which reads the data from the DOU and then 
executes the return. 


84 

85 ; ; 

a ; #** SUBROUTINE TO TAKE EXTERNALLY TRIGGERED READING #** 

T 3 

88 TRGR: 

89 MVI A,00000010B 3; LD RESET BIT 1 CONTROL WORD 

90 OUT CWR ; OUTPUT TO 8255#2 CNTL WD REG 
91 INR A. 3; MODIFY CONTROL WORD TO SET BIT 1 
92 OUT CWR ; OUTPUT TO 8255#2 CNTL WD REG 

93 TWT : ; ; 

gy IN FLG : ; INPUT THE BUSY FLAG 

95 ANT 001000008 ; TEST PORT C BIT 5 

96 JNZ TWT ; LOOP UNTIL NOT BUSY 

97 JMP TKDATA ; GO READ DATA FROM DOU AND RETURN 
98 ; — ‘ 
99 


The second method for reading the Fluke 8375 is - 
to rely on the sample rate set from the front panel 
controls and to wait until a full transition of the 
busy flag is observed. This guarantees that a previ- 
ous reading is not mistakenly interpreted as a new 
reading. | 


100 

101 ; 

102 ; **#* SUBROUTINE TO OBTAIN NEXT. READING *** 

103 ; 

104 NXTRD:. 

105 IN FLG ; INPUT THE BUSY FLAG 
» 106 ANI 001000008 ; TEST PORT C BIT 5 

107 JZ NXTRD ; LOOP UNTIL BUSY WITH NEXT READING 
- 108 NXTWT: 

109 IN FLG. ; INPUT THE BUSY FLAG 

110 ANI 001000008 ; TEST PORT C BIT 5 

111 JNZ NXTWT ; LOOP UNTIL NOT BUSY 

112 JMP TKDATA ; GO READ DATA FROM DOU AND RETURN 

113 ; a 


Notice that the loops beginning at NXTWT in the 
above program segment and at TWT in the previous 
program segment are identical. This suggests the 
possibility of some obvious code optimization that 
is omitted here for the sake of clarity. 


There is one subroutine remaining to complete full 
utilization of the Fluke 8375 DOU capabilities. It 
is the subroutine to take data from the 8375 DOU. 
The schematic (Figure 3) shows that port 5 (B) bits 
PB4—PBO are used to enable the DOU drivers. Data 
from the DOU includes: 


e 5 decades of digits 
e encoded range and overrange 
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e function: Volts DC, Volts AC, Ohms, Kil- 
ohms 
e modifiers: Filter, Ext. Ref., Remote 
@ overload 
e trigger 
The function of this subroutine is to read five 


bytes of data from the 8375 DOU and place them 
in a RAM buffer on the iSBC 80/10A. 


115 


116 ; 

117 ; *#* SUBROUTINE TO TAKE DATA FROM 8375 DOU ### 

118 ; 

119 TKDATA: 

120 LXI H, RDBUF ; LD BUFFER POINTER 

12) MVI A, OEFH ; SETUP FIRST STROBE 

122 TKO: 

123 MOV B,A ; SAVE CURRENT STROBE 

124 OUT STB ; STROBE DECADE PAIR 

125 IN DATIN ; READ DATA 

126 MOV MA ; PLACE DATA INTO SBC 80/10 RAM 
127 INX H ; INCREMENT BUFFER POINTER 

128 MOV A,B ; RESTORE STROBE 

129 RRC ; ROTATE TO NEXT STROBE POSITION 
130 JC TKO ; LOOP UNTIL BIT 0 STROBE DONE 
131 OUT STB ; DISABLE ALL STROBES 

132 RET 

133°3 

134 


This completes the software required to service the 
Fluke 8375 DOU. The following code consists of a 
routine to display the data from the interface on 
the console output device and a short executive 
program to allow exercising of the driver sub- 
routines. 

The display subroutine takes 5 bytes of data from 
the RAM buffer in which the reading has been 
stored and prints them, 2 ASCII characters per 
8-bit byte, on the console. 


135 
136 ; 
be ; *** SUBROUTINE TO DISPLAY READING BUFFER ON CONSOLE *## 
138 ; 
139 DISPLAY: 
140 LXI H, RDBUF ; LD BUFFER POINTER 
141 MVI D,5 ; INITIALIZE COUNTER 
142 DISPO: 
- 143 MOV AM ; LD NEXT BYTE FROM BUFFER 
144 CALL NMOUT ; CALL SBC 80/10 MONITOR SUBROUTINE 
145 ; TO DISPLAY ACCUMULATOR CONTENTS 
146 INX d ; INCREMENT BUFFER POINTER 
147 DCR D ; DECREMENT COUNTER 
148 JNZ DISPO ; LOOP FOR 5 DISPLAY BYTES 
149 RET 
150 ; 
151 


Operator Interface. The short executive program 
provides a tool for the purposes of exercising the 
8375 DOU driver subroutines. The executive begins 
by calling the initialization subroutine and then 
continues on to prompt the operator with a ‘*>’ on 
the console. At that point the operator may enter 
one of the following characters, causing the pro- 
gram to execute the specified subroutine: 


SUBR DESCRIPTION. 
T ETRIG Enable external trigger 
I DTRIG Disables external trigger 
E EPOS Enable programmed timeouts 
D DPOS Disable programmed timeouts 
N NXTRD Next reading 
S TRGR Trigger and get a reading 
X DISPLAY Display reading buffer 


After the operator has entered a command charac- 
ter, the program obtains the address of the sub- 
routine to be executed and proceeds to set up a 
return address on the stack. This technique allows 
a load program counter instruction (PCHL) to be 
used to enter the subroutine and a return instruc- 
tion (RET) to resume execution of the executive. 


152 
153 ; 
154 ; ¥**# SIMPLE EXECUTIVE EXERCISE PROGRAM ### 


155 ; 
156 START: 


157 LXI SP, STACK ; SETUP STACK POINTER 

158 CALL INIT ; INITIALIZE THE SBC 80/10 8255#2 
159 EXEC 

160 CALL CROUT ; EXEC ENTRY POINT - PRINT <CR><LF> 
161 MVI C.t>! ; C LOADED WITH PROMPT CHARACTER 

162 CALL co ; CONSOLE OUTPUT 

163 CALL GETCH ; GET CMND CHAR, MASK OFF PARITY 

164 CALL CO 3; PRINT THE CHARACTER ON THE CONSOLE 
165 MOV A,C ; PUT CHARACTER BACK INTO THE ACCUM 
166 LXI B,NCMDS ; C CONTAINS LOOP AND INDEX COUNT 
167 LXI H,CTAB ; HL POINTS TO CMND TABLE 

168 EXECO: 

169 CMP ; COMPARE TABLE ENTRY AND CHARACTER 
170 JZ EXEC1 ; BRANCH IF EQUAL - CMND RECOGNIZED 
171 INX ; ELSE, INCREMENT TABLE POINTER 

172 DCR C ; DECREMENT LOOP COUNT 

173 JNZ EXECO ; BRANCH IF NOT AT TABLE END 

174 JMP EXEC ; ELSE, CMND ILLEGAL - IGNORE IT 

175 EXEC1: 

176 LXI H,CADR ; LD ADR OF TABLE OF CMND SUBRS 

77 DAD B ; ADD WHAT IS LEFT OF LOOP COUNT 

178 DAD B 3; - EACH ENTRY IN CADR IS 2 BYTES 
179 MOV A,M ; GET LSP OF ADR OF TABLE ENTRY TO A 
180 INX H ; POINT TO NXT BYTE IN TABLE 

181 MOV H,M ; GET MSP OF ADR OF TABLE ENTRY TO H 
182 MOV L,A ; PUT LSP OF ADR OF TABLE ENTRY TO L 
183 LXI D, EXEC ; SETUP RETURN ADR ON THE STACK 

184 PUSH D 

185 PCHL ; NEXT INSTR COMES FROM CMND SUBR 
186 ; 

187 


The command and address tables as well as the 
reading buffer follow to complete the application 
software. 


188 

189 ; 

190 ; COMMAND AND ADDRESS TABLES 
, 

192 CTAB: 

193 DB 'XSNDEIT! 

194 NCMDS  EQU 3-CTAB ; NUMBER OF VALID COMMANDS 
, 

196 CADR 

197 Dw ) 

198 Dw ETRIG 

199 Dw DTRIG 

200 DW EPOS 

201 Dw DPOS 

202 DW NXTRD 

203 DW TRGR 

204 Dw DISPLAY 

205 ; 

206 ; READING BUFFER AND STACK SPACE 


207 ; 
208 RDBUF: 


209 DS 5 ; READING BUFFER 

210 ; 

211 

212 

213 END START ; TRANSFER-ADDRESS IS TO START 
SUMMARY/CONCLUSIONS. 


This instrumentation control application has been 
presented to demonstrate the simple techniques 
used to apply the iSBC 80/10A to the task of inter- 
facing instrumentation. A natural extension of this 
example would include the control of the Fluke 
8375 RCU, as well as the control of many addi- 
tional instruments to build a small ATE system. 
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COMMUNICATION... 


A diverse range of single board computer applica- 
tions exists in the field of communication. The 


increase in distributed processing generates require- 
ments for self-contained computers to control 
elements of a communication system, increasing 
both the throughput and reliability. 


There are many situations that necessitate monitor- 
ing and controlling a system from a remote site. 
Typical examples are systems that cover large geo- 
graphic areas or systems in dangerous environments 
for human operators. If the object system, which 
provides the actual parallel inputs and outputs to 
the plant, is far from the controlling system, you 
can lower costs by reducing the number Of inter- 


connecting wires via the addition of multiplexers 


to both systems. In the extreme (and often desira- 
ble) case of reducing the interconnects to an 
absolute minimum, all communication between the 
systems takes place on a single serial data link. If 
large distances are involved, this link can be stand- 
ard telephone wires. For moderate distances, the 
link can be a single twisted pair. In either case, the 
equipment used to interface the object system to 
the serial link is called a supervisory control and 
data acquisition (SCADA) terminal. 


The decision to replace a multitude of intercon- 
nects with a SCADA terminal is largely economic. 
Cables and their associated drivers and receivers 
can represent a significant part of the total cost of 
a factory automation project, particularly if an 
electrically noisy environment requires the use of 
shielded cables. Any potential savings in cabling 
must, of course, compensate for the additional cost 
incurred by adding the SCADA. terminal. to the 
system. 


Communication Application Example 

A SCADA terminal demonstrates an industrial com- 
munication application of the iSBC 80/10A. ‘The 
Intel® 8251 USART provides the serial communi- 
cation link and the two Intel 8255 Programmable. 
Parallel I/O devices provide 48 parallel lines for. the 


object system. A block diagram of a eee 


terminal is shown in Figure 4. 


The task of the software in: this SCADA terminal 
example is two-fold. First; it must continually scan 


its parallel inputs, transmitting the status of those 


lines in a bit serial mode using-the USART. And: 


second, it receives bit serial data from the USART 
which is to be used to update the parallel outputs. 


Thus, a major portion of the software deals with’ 


iSBC 80/10A 


PARALLEL’ 
OUTPUT 


SERIAL 
INPUT 


PARALLEL 
INPUT 


SERIAL 
‘ OUTPUT * 


Figure 4.. SCADA Terminal Block Diagram 


the communications protocol on the serial data 
lines. 


Communications Protocol. A communication pro- 
tocol is an agreement between communications 
users that defines the record formats used for data 
transmissions. The protocol selected for ‘this 
SCADA terminal application provides the follow- 
ing features: | 


1 A Saale: character set to siniplity the 
human interface. 


2.-Error detection by means of a checksum. 


Each record specifies the number of data 
bytes. in -the record and the initial port 
number. . , 


Despite its value for human entice: the ASCII 
character set has problems representing 8-bit 
binary values, since the high-order bit is not used. 
Therefore, each binary value is treated as two 4-bit 
hexadecimal values. Because hexadecimal numbers 
fall in the range O—9 and A—F, they can be repre- 
sented as ASCII characters. However, this repre- 
sentation reduues twice as many bytes as a pure 
binary format. m4 


Record Format. The information encoded into the 
ASCII hexadecimal format is grouped to form 
records. Each record has a record mark to flag the 
beginning of the record, a number of ports specifi- 
fication (record length), destination output start 
port number, the data field itself, and a checksum. 


The record format described below is according to 
the fields in the record. 


Record mark field: Byte O 


The ASCII code for a colon (: ) is used to. signal 
ene start of a EeCONes 


Naber of sare field: Byte Es 


~The number of data bytes in the record is repre- 
sented by a single ASCII hexadecimal digit in this 
field. This corresponds to the number of 8-bit 
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ports to which data will be output by the 
SCADA terminal in a parallel fashion. The maxi- 


mum number of data bytes in a record is 15 (F 


in hexadecimal). A record length of zero is a 
special case and can be reserved for control 
information. 


Port address field: Byte 2 


The single ASCII hexadecimal digit in byte 2 
gives the port number of the initial ‘output port. 
The first data byte is output to the port indi- 
cated by the port address; successive bytes are 
output in successive port locations on the iSBC 
-80/10A or on expansion I/O boards. 


Data field: Bytes 3 to 3+2*(number of ports)—1 
An 8-bit binary value is represented by two 
bytes containing the ASCII characters 0-9 or 
A-—F, which represent a hexadecimal value 
between O and FF (0 and 255 decimal). The 
high-order digit is in the first byte of each pair. 


Checksum field: Bytes 3+2*(number of poe to 
3+2*(number of ports)+1 


The checksum field contains the ASCII hexa- 
decimal representation of the two’s complement 
of the 8-bit sum of the 8-bit bytes that result 
from converting each pair of ASCII hexadecimal 
digits to one byte of binary, from the number of 
ports field (the number of ports and port ad- 

_ dress constitute a pair) to.and including the last 
byte of the data field. Therefore, the sum of all 
the ASCII pairs in a record after converting to 
binary, from the number of ports field to.and 
including the checksum field, is zero. 


Sample Hexadecimal format: 
:303A178 EFO 


| Le 


Checksum Field 
Data Field 


Starting Port Address 


Number of Ports . 


Record Mark 


Design Approach Using a State Diagram. Before 


proceeding to examine the software used to imple- 
ment the SCADA terminal; consider how the prob- 
lem might have been approached with TTL logic 
rather than a microcomputer. The design would 


likely have been formulated with a state diagram to’ 


specify the transitions of a sequential state ma- 
chine. The. sequential-circuit operations would 
include decoding the serial input records and 


encoding the serial output records. An examination 
of the serial input record state diagram (Figure 5) 
is useful in understanding some of the procedures 
encountered later. 


INIT 


Figure 5. State Diagram 


Hexadecimal ASCII character _ : 


Notes: HAC = 
LHAC = Last Hexadecimal ASCII character 


PO Parallel output 


The receipt of an invalid HAC will cause a return 
to state 0. 


The receipt oh a colon at any time will produce a” 
transition to state 1. 


STATE — DESCRIPTION — 
O = record mark state . 
1 = number of ports state 
2 = start port number state a 
3 = high-order half of data byte state 
4 = low-order half of data byte state 


State 0 is entered at the time of initialization. All 
state transitions occur when the next character is 
received. States 1, 2, and 3 are entered with the 
input of a colon (: ), the number of ports and start 
port number, respectively. States 3 and 4 will cycle 
as required until all the high and low-order pairs of 
data have been input. The transition from state 4 
to state 0 occurs when the last data byte has been 
received, If the checksum is correct, the parallel 
output latches are loaded with the data ios of 
the record. 


There are many prerenees to the states eeaiained 
in this diagram during the discussion of. the soft-. 
ware procedures. Thus, the state diagram is ‘used as 
a “flowchart”? for the software. As in the other 
examples in this application note, a textual descrip- 
tion accompanies each segment. of code. Intel’s 
high-level programming language, PL/M-80, - has 
been used to show the capability to program in a 
natural, algorithmic language which eliminates the 
need to. manage. ee usage or memory aOca- 
tion. 
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SCADA Terminal Program. The program begins 
with a comment, that is followed by the program 
segment label “SCADA”. With resident PL/M-80, 
all programs are considered to be labelled blocks, 
or modules. This means that all PL/M programs 
must begin with a LABEL and a DO statement and 
end with an END statement. | 


/* 
INDUSTRIAL COMMUNICATION APPLICATION 
SCADA TERMINAL 
#/ 
1 SCADA: 
DO; 


All variables used in the program must be declared 
before they can be referred to by their identifiers. 
This is done by means of a DECLARE statement. 
In addition to the declaration of variables, macros 
are declared using the reserved word LITERALLY. 
These macros are expanded at compile time by 
textual substitution. 


2.1 DECLARE 
SRL$IN$STATE BYTE, 
SRL$IN$PRT BYTE, 
SRL$IN$CNT BYTE, 
PRL$IN$STATE BYTE, 
PRL$ING$STRT$PRT BYTE, 
PRL$INSNMB$PRTS BYTE, 
SRL$IN$PRL$OUT$BFR(3) BYTE, 


PRL$OUT$PRT$O LITERALLY 'OE5H', 
PRL$OUT$PRT$1 LITERALLY 'OEAH', 
PRLSOUT$PRT$2 LITERALLY 'OE8H', 


SRL$OUT$STATE BYTE, 
SRLSOUT$PRT BYTE, 
SRL$OUT$CNT BYTE, 
PRL$OUT$STATE BYTE, 
PRL$OUT$STRT$PRT BYTE, 
PRL$OUT$NMB$PRTS BYTE, 
SRLGOUT$PRL$IN$BFR(4) BYTE, 


PRL$IN$PRT$O LITERALLY 'OE4H', 
PRL$IN$PRT$1 LITERALLY 'OE6H', 
PRL$IN$PRT$2 LITERALLY 'OE9H', 


USART$CMD LITERALLY 'OEDH', 
USART$IN LITERALLY 'OECH', 
USART$OUT LITERALLY 'OECH', 
USART$STATUS LITERALLY 'OEDH', 
USART$MODE$INSTR LITERALLY 'OCFH', 
USART$CMD$INSTR LITERALLY '025H', 


TXRDY LITERALLY 'OO1H', 
RXRDY LITERALLY '002H', 


‘ PPI$CWR$1 LITERALLY 
PPI$CWR$2 LITERALLY 
_ PPI$CWD$1 LITERALLY 
PPI$CWD$2 LITERALLY 


TRUE LITERALLY 'OFFH', 
FALSE LITERALLY 'QOOH', 


'OE7H', 
‘OEBH', 
'080H", 
'O9BH', 


FOREVER LITERALLY ‘WHILE TRUE', 


NEXT$BYTE BYTE, 
CHECKSUM BYTE; 


8251 and 8255 Initialization. The INIT procedure 
sets up the 8251 and 8255’s and initializes several 
variables. Interrupts are disabled to insure that no 


interrupts are serviced during the execution of the. 


INIT procedure. 


INIT: PROCEDURE; 
DISABLE; 


The serial input and serial output state counters are 
set to state 0. Port number O is the parallel input 
start port and 3 ports of data are input from the 
parallel ports for serial transmission. 


5 2 SRL$IN$STATE = 0; 
6 2 SRL$OUT$STATE = 0; 
T 2 PRL$IN$STRI$PRT = 0; 
8 2 PRL$IN$NMB$PRTS = 3; 


The Intel 8251 USART must be set up by loading 
it with mode and command instructions. 


The mode instruction format is shown below: 


BAUD RATE FACTOR 


00 > SYN MODE 
01> ASYN X1 

10 > ASYN X16 
11> ASYN X64 


CHARACTER LENGTH 


00 >S5BITS 
01->6BITS 
10-7 BITS 
11-8 BITS 


PARITY CONTROL 


X 0 = NO PARITY 
01 > ODD PARITY 
11> EVEN PARITY 


FRAMING CONTROL 


00 > NOT VALID 
01+ 1STOP BIT 
10 >1%STOP BITS 
14 = 2STOP BITS 


NO — ASYN (D1 Dg # 00) 


SYN CONTROL 


X0 INTERNAL SYN 
X 1 EXTERNAL SYN 

0X DOUBLE SYN CHAR 
1X SINGLE SYN CHAR 


The 8251 characteristics required by this SCADA 
terminal application include 9600 baud transmis- 
sion and 8-bit characters. The parallel inputs of the 
8255’s are periodically scanned. The scanning 
frequency is determined by the baud rate and 
number of ports of data being transmitted. For 
example, the transmission of 3 ports of data 
requires 11 characters. At a baud rate of 9600 the 
approximate scan rate is 100 Hz. 


The following 8251 mode instruction is used: 


Pt popota tty 


LS 


Instruction = 1100 1110 Binary = CEH 


‘Baud Rate Factor = 10 
Character Length = 11 
Parity Control = 00 


Framing Control = 11 
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After the mode instruction is:sent to the 8251, a 


command instruction is peaniece to complete the 


8251. initialization: 


The command instruction format is shown below: 


TTRANSMIT ENABLE 
1= ENABLE 
0 = DISABLE: 


DATA TERMINAL 
READY 


“HIGH” WILL FORCE ~ 
OTR OUTPUT TO ZERO | 


RECEIVE ENABLE 
1= ENABLE RxRDY 
0 = DISABLE RxRDY 


SEND BREAK 

CHARACTER 

' 1= FORCES TxD “LOW” 

- 0= NORMAL OPERATION 


ERROR RESET 
1= RESET ALL ERROR 
FLAGS (PE, OE, FE) 


REQUEST TO SEND 
“HIGH” WILL FORCE 


RTS OUTPUT TO ZERO 


INTERNAL RESET 
“HIGH” RETURNS 8251 
TO MODE INSTRUCTION 
FORMAT , 


ENTER HUNT MODE 
1 = ENABLE SEARCH FOR 
SYN CHARACTERS 


The command instruction enables the transmit and 
receive functions of-the 8251. 


The following command instruction is used: 


Transmit Enable = 1 

Data Terminal Ready = 0° 
- Receive Enable = 1 

Send Break Character = 0 
, Error Reset=0 . 
Request to Sands 1 


‘Internal Reset=O . - 


Enter Hunt Mode = 0 


Instruction = 0010 0101 Binary = 25H 


Output instructions send. the initialization com- 
mands to the 8251. Note that previously declared 
macros are used to literally replace the mnemonics 
in the following lines of code. 


OUTPUT ( USART$CMD) 
OUTPUT( USART$CMD) 


USART$MODE$INSTR ; 
USART$CMD$INSTR ; 


oat 
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Initialization of the 8255’s.is then done to set up: 
the geil: eosurations. 


8255 #1. 7 - 
Port age : Mode O° Output | | 
Port 2(B) Mode dO Output © 
Port 3(C) ModeO Output _ 
8255 #2 
Port 4(A) ModeO Input 
Port 5(B) ModeO Input 
Port 6(C) ModeQO Input 


The following: command instruction: is used for the 
8255: iN | | | : 


[27 [6] 5] Ps] Ps] 2] Os] D0 


Port C Bits PC3—RCo Output =0 


Port 8 Output ='0. « * 


Port B Mode 0 = 0 
Port C Bits PC7—PC4 Output = 0 
‘ Port A Output =0 

Port A Mode = 00 
Opcode inieia Set =1 


Mode Control Word = 1000 0000 Binary = 80H . 


The following command instruction is used for the 
8255 #2: : 


Port C Bits PC3~PCg Input = 1 


- Port B Input'=.1 


Port B Mode 0 = 0 
Port C Bits po7-PC4 Input = 1 
Port A Input = :4 
__ Port A Mode = 00 
i Opcode Mode Set = 1 


Mode Control Word = 1001 1011 Binary= 9BH_ 


The 8255 initialization commands are given in a 
similar manner to the 8251 commands. 


PPTSCuD$ 13 


OUTPUT( PPI$CWR$1). | 
PPI$CWD$2; 


<.- OUTPUT(PPI$CWR$2) = 


The INIT procedure Boncliides. by enabling inter- 
rupts. 


ENABLE ; 


END INIT; 
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Conversion Procedures. Two conversion procedures 
are required in the program. The first procedure 
produces a hexadecimal ASCII character from a 
4-bit binary value. A typed procedure has been 
used which returns a value of the type byte. It is 
called by using its name in an expression. 


1 CHAR$CONV: PROCEDURE (CHAR) BYTE; 
2 DECLARE CHAR BYTE; 
2 CHAR = CHAR + '0'; 
18 2 IF CHAR > '9' THEN 
2 CHAR = CHAR + 7; 
2 RETURN CHAR; 
2 


END CHAR$CONV; 


The second procedure produces a 4-bit binary 
value from a hexadecimal ASCII character. Because 
this procedure is used only when a hexadecimal 
ASCII character is expected, an illegal character 
(i.e., not a O—9 or A—F) causes the serial input 
state counter to indicate state 0. This procedure is 
also typed. The NMB$CONV procedure emphatic- 
ally illustrates the point that PL/M-80 performs 
unsigned arithmetic. Note that when the ASCII 
value for a zero is subtracted from the digit, 
NUM = NUM -— ‘0’; a positive number is always 
produced, even if the value of NUM is less than ‘0’. 


NMB$CONV: PROCEDURE (NMB) BYTE; 
DECLARE NMB BYTE; 


NMB = NMB - '0'; 
ae NMB > 9 THEN 


1 
2 
2 
2 
2 
273 "IF (NMB > 16) AND (NMB < 23) THEN 
3 N MB - 7; 
ELSE 
3 SRL$IN$STATE = 0; 
3 . 
2 RETURN NMB; 
2 


END NMB$CONV; 


Parallel Input Procedure. A parallel input proce- 
dure is used to input data bytes from the 8255’s. 
The data bytes are then transmitted by the bit 
serial output device. This procedure also computes 
the checksum for the serial output record. The 
checksum, TEMP2, is initialized to contain the 
parallel input number of ports and the start port, 
shifted to fit within a single byte. Each cycle of the 
iterative DO block adds the next data byte to the 
checksum and places the input data into the 
SRLSOUT$PRLSIN$BFR array until the loop is 
complete. The checksum is then computed as the 
two’s complement of the accumulated sum and 
also stored in the serial input parallel output 
buffer. 


PARALLEL$IN: PROCEDURE; 


1 
34° 2 DECLARE (TEMP1,TEMP2) BYTE; 
35 2 TEMP2 = PRL$IN$NMB$PRTS # 16 + PRL$IN$STRT$PRT; 
36 2 DO PRL$IN$STATE = PRL$IN$STRT$PRT TO | 
PRL$IN$STRI$PRT + PRL$IN$NMB$PRTS - 1; 

7 63 DO CASE PRL$IN$STATE; 

/* PRL IN PRT 0 # 
338 C4 TEMP1 = INPUT(PRLSTINSPRT$O) : 

/* PRL IN PRT 1 #/ 
39° «4 TEMP1 = INPUT(PRL$IN$PRT$1) ; 


/* PRL IN PRT 2 # 
TEMP1 = INPUT( (PRLSENGPRTS2) ; 


END; 


4 
4 
3 ee = TEMP1; 
430 3 TEMP2 = TEMP2 + ; 
3 
2 
2 


END; 
SRL$OUT$PRL$INGBFR( PRL$IN$STRT$PRT + PRLSINGNMB$PRTS) = -TEMP2; 


END PARALLEL$IN; 


Parallel Output Procedure. When a complete serial 
input record has been received and the checksum is 
correct, the transition from state 4 to state O is 
accompanied by the parallel output of the data 
from the data field of the serial input record. The 
parallel output starting port and the number of 
ports of data is contained in the input record and 
is thus used in directing the parallel output opera- 
tion. An iterative DO block increments the 
PRLS$SOUTSSTATE index variable through the 
required ports and a DO CASE block selectively 
executes one of the OUTPUT statements for each 
cycle of the loop. 


474 PARALLEL$OUT: PROCEDURE; 
4B 2 DECLARE TEMP BYTE; 
49 2 DO PRL$OUT$STATE = PRL$OUT$STRT$PRT TO 
PRL$OUT$STRI$PRT + i aa ta - 1; 

50 3 TEMP = SRL$IN$PRLGOUT$BFR(PRL$OUT$STATE) ; 
513 DO CASE PRL$OUT$STATE; 

/* PRL OUT PRT 0 
52.4 QUTPUT( PRLSOUTSPRTSO) = TEMP; 

/* PRL OUT PRT 1 

53 4 cuTeUTC PRL SOUTSPRTS) = TEMP; 

/* PRL OUT PRT 


2* 
OUTPUT PRLSOUTSPRT#2) = TEMP; 


END; 
END; 


wn 
fon 
Ny We ££ 


END PARALLEL$OUT; 


Serial Input and Output Procedures. The next two 
procedures contain the software implementations 
of the state diagram described previously. The 
processing during each state of the first procedure, 
the serial character input procedure, is described 
in the following text. 


The procedure begins by penaiad a diineacier from 
the 8251 and then converts the character into a 
4-bit binary value using the number conversion 
procedure. The DO CASE block is the mechanism 
by which a program segment is selected to examine 
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the input character, provide the required outputs, 
and to specify the transition to the next state. 


58 1 SERIAL$CHAR$IN: PROCEDURE; 


59 2 DECLARE (CHAR,TEMP) BYTE; 
60 2 CHAR = INPUT(USART$IN) AND O7FH; 
61 2 TEMP = NMB$CONV(CHAR) ; 

2 


62 DO CASE SRL$IN$STATE; 

State 0 is entered through the initialization proc- 
ess, at the completion of the processing of a serial 
input record, or when an invalid character has been 
received. The serial input state will remain O until a 
colon (:) is received, at which time a transition to 
state | is specified. 


/* SRL IN STATE 0 = RECORD MARK */ 


63. 3 
. 64 4 F CHAR = ':' THEN 
65 4 SRL$IN$STATE = 1; 
66. 4 7 


END;. 


The parallel output number of ports is obtained, 
the counter initialized, and a transition to state 2 is 
specified from state 1. 


je SRL IN STATE 1 = “NMB PRTS + 


67 3 

68 4 " PRLSOUTSNMBSPRTS = = TEMP; 
69 4 SRL$IN$CNT = TEMP; 

70 4 SRL$IN$STATE = 2; 

1 O4 


BND; 


In state 2 the parallel output starting port number 


is obtained, the serial input port is initialized, the 


checksum is set to contain the parallel output 
number of ports and starting port, and a transition 
to state 3 is specified. 


/* SRL IN STATE 2 = STRT PRT #/ 


72 3 DO; 

73, =4 PRL$OUT$STRT$PRT = TEMP; 

mH 4 SRL$IN$PRT = TEMP; 

15 4 CHECKSUM = PRLSOUTSNMB$PRTS* 16 + PRL$OUT$STRT$PRT; 
7% 4 SHINE = 3; 

7 4 END; 


In state 3 the high-order half of a data byte is 
obtained and shifted into the proper position of 
the NEXTSBYTE variable. A transition is specified 
to state 4. 


/* SRL IN STATE 3 = HI ORDER HALF DATA BYTE #/ 


END; 


78 3 3 
79 «4 NEXT$BYTE = TEMP#16; 
80 i SRL$IN$STATE = 4; 


State 4 is the final'’state and requires more process- 
ing than the others. First, a whole byte of data is 
assembled by adding the low and high-order data 
halves, and then testing to determine if the check- 
sum has been received. If so, and the checksum is 
correct, the parallel output procedure is executed. 
Once the entire serial input record has been re- 
ceived, a transition is specified to state 0 whether 
the checksum is correct or not. However, if the 


serial input count has not been exhausted, the 
assembled byte is placed into the serial. input 
parallel teas baie and a transition back: to state 
3 is speciteg 


yt SRL IN STATE 4 = LO ORDER. HALF DATA BYTE */ 


82 3 ; 
83 4 NEXT$BYTE = NEXT$BYTE + TEMP; 
By CHECKSUM = CHECKSUM + NEXT$BYTE; 
85 4 IF SRL$IN$CNT = 0 THEN 
86 4 DO; 
87 5 IF CHECKSUM = O THEN 
88 5 ’ CALL PARALLEL$OUT; 
89 5 SRL$IN$STATE = 0; 
go 5 D; 
ELSE 
gi 4 
92. 5 fia TAUBREGGUTSARRCERISTNCORT) = NEXTSBYTE: 
93 5 SRL$IN$PRT = SRL$IN$PRT + 1; 
94 5 SRL$IN$CNT = SRL$IN$CNT - 1; 
9 5 SRL$IN$STATE = 3; 
96 5 END; 
oa | END; 
98 3 END; /* END OF CASES #/ 
99 2 END SERIAL$CHAR$IN; 


The serial character output procedure is similar to 
the serial character input procedure. During state 0 
the parallel inputs of the 8255’s are stored in the 
serial output parallel input buffer for transmission. 


100 1 SeRIALSOHARHOUT: PROCEDURE; 


101 2 DECLARE (Car, TEMP) BYTE: 
“102-2 CHAR = 0; 7 
103 2 “DO CASE SRESOUT$STATE; 
ia /* SRL OUT STATE 0 = RECORD MARK */ 
104. 3 00; 
105 CHAR = tts 
1064 CALL PARALLBLSIN: 
1074 SRLSOUT$STATE = 1; 
1084 END; 
/* SRL OUD STATE 1 = NMB PRTS */ 
10 4 TEMP = PRL$IN$NMBSPRTS: ° 
W104 SRL$OUT$CNT = TEMP; 
W204 SRLSOUT$STATE = 2; ° 
11304 END: | . 
/* SRL OUT STATE 2 = ‘STRT PRT */ 
114 3 ‘ 
15 4 - “TEMP = PRLSIN$STRT$PRT; 
116 4 SRLS$OUT$PRT = TEMP; 
N74 SRL$OUT$STATE = 3; 
118 4 END; : : 
/* SRL OUT STATE 3 = HI ORDER HALF DATA BYTE #/ 
119 3 DO; . 
120 4 TEMP = SHR(SRLS$OUT$PRL$INGBFR(SRL$OUT$PRT) , 4) ; 
121. 4 SRLSOUT$STATE = 4; 
122 «4 END; . ; 
/* SRL OUT STATE 4 = LO ORDER HALF DATA BYTE #/ 
123 3 DO; 
124 TEMP = SRLSOUTSPRLSINSBPR(SRLEOUTSPRT) AND OFH; 
125 4 IF SRLSOUT$CNT = 0. 
126 4 - SRLSOUTSSTATE = ¢ be 
. ELSE . 
127 3244 ra o a7 
128 5 SRL$OUTSCNT = SRL$OUT$CNT = 1; 
129. 5 “ SRL$OUT$PRT =!SRL$OUT$PRT + 1; 
130 5 SRL$OUT$STATE = 3; 
Bis S END; | 
132 END; 
133. 3 BND; /* END OF CASES */ 
134-2 “IF CHAR <> ':' THEN 
135 2 CHAR = CHAR$CONV(TEMP) ; 
136° 2 OUTPUT(USART$OUT) ‘= CHAR; 
aq 2 


' END: SERIAL$CHAR$OUT; | 


Interrupt Service Routine. The. software. in this 
SCADA terminal application example is interrupt. 
driven. Interrupts, which occur when the trans- 
mitter of the 8251 is ready for another character 
of when the receiver has obtained a serial charac- 
ter, direct the execution of either the serial input. 
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or output character procedures. The following 
procedure is entered when an interrupt occurs. 


1381 USART$INTERRUPT: PROCEDURE INTERRUPT 7; 


139-2 ‘DECLARE STATUS BYTE; 

140 «02 STATUS = INPUT(USART$STATUS) ; 
1442 IF (STATUS AND TXRDY) = TXRDY THEN 
42 2 CALL SERIAL$CHAR$OUT ; 

143002 IF (STATUS AND RXRDY) = RXRDY THEN 
Hy 2 CALL SERIAL$CHAR$IN; 

145 2 


END USART$INTERRUPT; 


Main Program. The function of the main program 
is rather simple. It calls the initialization routine 
and then loops “FOREVER.” Notice that the 
other software-is executed only when an interrupt 
occurs. Rather than loop idly while waiting for an 
interrupt, the “‘main program” could take advan- 
tage of excess CPU time by processing some other 
task. 


Wet r tr ere’ 
MAIN$PROGRAM: 


RRRKEERARH SE / 


6 4 CALL INIT; 


147 
Wa 2 


= 


DO FOREVER; 
END; 


1491 END; 
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SUMMARY/CONCLUSIONS 


Further consideration should be given to error 
checking in the implementation of a SCADA termi- 
nal. A checksum has been used in this example 
which provides some error detection but no 
correction. | 


The industrial communication example in this 
application note has shown a SCADA terminal. 
Besides providing a convenient forum in which to 
explore the use of PL/M in an interrupt-driven 
environment, this application provides a realistic 
and almost fully-developed tool for the replace- 
ment of a multitude of parallel lines. Two such 
systems can be connected through the serial lines 
to provide a parallel to parallel transmission 
scheme as shown in Figure 6. 


PARALLEL I/O PARALLEL I/O 


SERIAL 1/0 


SCADA TERMINAL 


SCADA TERMINAL 


Figure 6. Two SCADA Terminals. 
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Figure 7. SCADA Terminal Schematic 
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PROCESS CONTROL 


Many single board computers have already been 
applied in the field of process control. Some of the 
common denominators observed in these applica- 
tions include the use of A/D and D/A peripheral 
boards, process monitoring functions such. as 
servicing display panels for operator interaction, 
and alarm indicators. 


Temperature Monitoring Application Example 


A temperature monitoring system has been devel- 
oped for the purposes of a process control applica- 
tion example. The single open loop system utilizes 
an A/D converter, a multiplexed display, switches 
for operator control, and two alarms. A block dia- 
gram of the operator’s panel is shown in Figure 8 
and a schematic in Figure 9. 


TEMPERATURE MONITORING 


iSBC 80/10A OPERATOR'S PANEL 


PORT 5 (B) 


SWITCH 
INPUT 


7-SEGMENT 


GROUP #2 
8255 DATA 


DIGIT SELECT & 
ALARM 
INDICATORS 


Figure 8. Operator’s Panel Block Diagram 


Operator’s Panel. The operator’s panel in this 
temperature monitoring system contains four 
7-segment displays to show the temperature, two 
light emitting diodes (LEDs) that indicate alarm- 
low and alarm-high conditions, and six switches. 
The function of the switches is as follows: 


Set Limit — controls whether the current 
temperature reading is to be displayed (off) or 
if upper/lower limits are to be set (on). 


Set Hi Lo — when set:limit is “‘on”’, this switch 
- controls whether the low (off) or high (on) 
limit is to be displayed. - 3 


Digit Selects — these two switches control the 
selection of the digit of the limit which is to 
be modified. The four binary positions 00, 
01, 10 and 11 correspond to the four 7- 
segment digits. - 7 o_o 3 
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Leave It — controls whether the digit selected 
is to be incremented (off) or maintained at its 
current value (on). When this switch is “off” 
the digit selected is incremented every 512 ms 


until the operator turns the switch ‘‘on’’. 


Enable Alarm — when set limit is “off”? and the 
current temperature is displayed, this switch 
controls whether the action of the alarm indi- 
cators is to be enabled (on) or disabled (off). 


The simple means used to set upper and lower 
temperature limits is similar to setting the time on 
a digital wrist watch. 


The purpose of the software is to initialize the 
system and then to enter an endless loop which 
accumulates 16 readings, updates the displayed 
reading or handles limit setting, updates the display 
latches, waits 4 ms, and obtains an A/D reading. 


Temperature Monitoring Program. This application 
example has been coded in Intel’s resident PL/M- 
80 language. 


# 
PROCESS CONTROL APPLICATION 


OPEN LOOP 
TEMPERATURE MONITOR 
#/ 
1 TEMPERATURE$MONITOR: 


DO; 


The declaration statement includes some dimen- 
sioned variables with INITIAL attributes. They 
provide data strobe positions, a table of bit pat- 
terns to convert BCD data to 7-segment data, and 
a table of the powers of 10 for binary to BCD 
conversions. | pie x | 


2.61 DECLARE 
READING ‘ADDRESS, 
DIGITS(4) BYTE INITIAL (80H,40OH,20H, 10H), 
BCDTO7SEG(11) BYTE INITIAL (3FH,06H,5BH, 4FH, 66H, 
6DH,7CH,O7H,;7FH, 67H, 0), 
TENS(4) ADDRESS INITIAL (1000,100,10,1), 


DIGIT$DATA(4) BYTE, 
NXT$DIGIT BYTE, 
UPDATE$COUNT BYTE, 
SET$COUNT BYTE, 
- LIMIT(2) ADDRESS, 
ACCUM$RDNG ADDRESS, 


CWR LITERALLY 'OEBH', 

SLCT LITERALLY 'OERAH', 

SEGS LITERALLY 'OE8H', 

SWTS LITERALLY 'OE9QH', _ 
SETUP$PORTS LITERALLY '082H', 


SET$LIMIT LITERALLY 'OO1H', 
SET$HI$LO LITERALLY '002H', 
LEAVE$IT LITERALLY '010H', 
DIGIT$SLCT LITERALLY 'OOCH', 
. ENABLE$ALARM LITERALLY '020H', — 

SET$ALARM$LO LITERALLY '001H', 

* . SET$ALARM$HI LITERALLY '003H', 
RESET$ALARM$LO LITERALLY 'OOOH', 
RESET$ALARM$HI LITERALLY '002H', 


TRUE LITERALLY -OFFH', 
FOREVER LITERALLY 'WHILE TRUE'; 
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The analog to digital conversion procedure has 
been coded in assembly language and is not in- 
cluded in this application note. It is declared as an 
external typed procedure with no arguments and 
returns a value of the type address. The value 
returned is the current temperature. The ATOD 
procedure is linked later in a step to produce an 
absolute load module of the entire program. 


g.4 ATOD: PROCEDURE ADDRESS EXTERNAL; 
ae! END ATOD; 


Bit set/reset functions of the 8255 have been used 
to control the alarm-low and high output bits. Use 
of this function allows individual bits to be con- 
trolled without affecting others of port C which 
are concurrently selecting the digit to be multi- 
plexed on the display. 


'  RESET$ALARMS: PROCEDURE; 


; 
2 OUTPUT(CWR) = RESET$ALARM$LO; 
2 OUTPUT(CWR) = RESET$ALARM$HI; 
2 


ann wv 


END RESET$ALARMS; 


The following procedure is used to initialize the 
8255 and several program variables. 


1 INIT: PROCEDURE; 
2 OUTPUT(CWR) = SETUP$PORTS; 
2 CALL RESET$ALARMS; 
2 NXT$DIGIT = 0; 
2 UPDATE$COUNT = 0; 
1h 2 SET$COUNT = 7; 
2 READING = 0; 
2 ACCUM$RDNG = 0; 
2 LIMIT(O) = 0000; 
2 LIMIT(1) = 9999; 
2 


END INIT; 


A multiplexed display is controlled by the soft- 
ware. Two. ports of an 8255 are required for this 
function shown in Figure 9. The first output port 
holds the data which drives the four 7-segment dis- 
plays in parallel. The second output port contains 
four strobes, each going to a separate common 
cathode of one of the 7-segment displays. 


The update display procedure begins by blanking 
7-segment data in the output port. This step avoids 
shadows that would be produced if the data for 
the next digit position were loaded prior to up- 
dating the strobe. The strobe is then advanced, 
retaining the alarm bits that occupy other bits of 
the same output port. Note that an output con- 
figured 8255 port can be read. with an 8080A 
INPUT instruction to determine the currently 
latched output data. The BCD data is obtained 
from the next digit position of the DIGIT$DATA 
array and used as a subscript into a table of 
BCDTO7SEG data. The 7-segment data is also 


output to the 8255 port in the same statement. 
The procedure concludes by advancing the 
NXTS$DIGIT pointer. | | 


1 DISPLAY$UPDATE: PROCEDURE; 
2 OUTPUT( SEGS) = 0; 
2 OUTPUT(SLCT) = (DIGITS(NXT$DIGIT) OR (INPUT(SLCT) AND 03H)); 
23. 2 OQUTPUT(SEGS) = BCDTO?SEG( DIGIT$DATA(NXT$DIGIT)) ; 
2 '. .NXT$DIGIT = (NXT$DIGIT+1) AND 03H; .. 
2 


END DISPLAY$UPDATE; 


Binary to BCD Conversion. Binary data from the 
A/D converter must be converted to BCD before it 
can be used by the DISPLAYSUPDATE procedure 
to show the current temperature reading. The 
BINTOBCD procedure performs this conversion 
operation. 


BINTOBCD: PROCEDURE; 
DECLARE (BCD,I) BYTE; 


DO I = 0 TO 3; 


BCD = 0; 
DO WHILE READING >= TENS(I); 


READING = READING - TENS(1) 5 
BCD = BCD + 1; 


END; 
DIGIT$DATA(I) = BCD 
END; 


Ww 
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END BINTOBCD; 


BCD to Binary Conversion. The reverse conversion ~ 
process is also needed. That is, BCD data must be 
converted to binary. This procedure is used to take 
limits, which are set by manipulating BCD digits, 
and convert them to binary data for use in testing 
against current temperature readings. Based vari- 
ables have been used in. this procedure to allow 
access to the actual variables used as arguments in 
the calling program. 


37 1 — -BCDTOBIN: PROCEDURE SOR ANON 


332 DECLARE 
(BCD$ARRAY$ADR, BINSDATASADR) ADDRESS, 
(BCD$ARRAY BASED BCD$ARRAY$ADR) (4) BYTE, 
(BIN$DATA BASED BIN$DATA$ADR) BOUEES Sa 


I BYTE; 
39 2 ae = 0; 
4o 2 DO dee ; 
/* BINSDATA = BIN$DATA*10 + BCD$ARRAY(I) #/ 
“Wy 30. BIN$DATA = SHL(BIN$DATA,1) + SHL(BIN$DATA,3) + BCD$ARRAY(I); 
42 3 END; 
4302 END BCDTOBIN; 


Updating the Display. The UPDATE procedure is 
entered each time 16 readings have been taken 
from the A/D converter. The UPDATE$COUNT is 


_ reset and the operator switches are input to control 


the execution path through the procedure. The 
accumulated reading, which is the total of 16 A/D 
readings, is divided by 16 to obtain an average 
reading. Then the accumulated reading is zeroed. 
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yy] UPDATE: PROCEDURE; 


45 2 DECLARE (SWT$FLG,HI$LO,DIGIT) BYTE; 
46 2 UPDATE$COUNT = 15; 

47 2 SWT$FLG = INPUT(SWTS); 

48 2 READING = SHR(ACCUM$RDNG, 4) ; 

492 ACCUM$RDNG = 0; 


Setting Limits. If the set limit switch is ON, the 
limits are to be dealt with instead of testing and 
displaying the current temperature reading. The 
alarms are reset during limit setting. The specified 
limit is converted to BCD and then the Leave-It 
switch is tested to see if the digit selected is to be 
incremented or held constant. 


50 2 IF (SWI$FLG AND SET$LIMIT) = SET$LIMIT THEN 
51 2 ; 

52. 3 CALL RESET$ALARMS; 

53. 3 HI$LO = SHR((SWT$FLG AND SET$HI$L0),1); - 
54 3 READING = LIMIT(HI$LO) ; 

5 3 CALL BINTOBCD; 

56 3 IF (SWT$FLG AND LEAVE$IT) <> LEAVE$IT THEN 


Another counter is used to control digit incre- 
menting. Its purpose is to control the rate at which 
the selected digit is to be incremented. The major 
loop in the program has a 4-millisecond delay. 
Thus, 16 A/D conversions require a period of 
64 ms which provides an update frequency of 16 
readings per second. This is too fast to accurately 
select a desired digit which is being incremented. 
SET$COUNT insures eight update periods (512 
ms) between each increment. After the digit has 
been incremented, the BCD limit value is con- 
verted back to binary to set the respective limit. 
This concludes the action taken when setting 
limits. 


DO; 
IF SET$COUNT = O THEN 


’ 
SET$COUNT = 7; 
DIGIT = SHR((SWT$FLG AND DIGIT$SLCT) ,2); 
IF DIGIT$DATA(DIGIT) = 9 THEN 
DIGIT$DATA(DIGIT) = 0; 
SE 


DIGIT$DATA(DIGIT) = DIGIT$DATA(DIGIT) + 1; 
CALL BCDTOBIN( .DIGIT$DATA, .LIMIT(HI$LO)); 
END; 
ELSE 
SET$COUNT = SET$COUNT ~ 1; 
END; . 
END; 


fon) 
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Testing the Averaged Reading. If the set limit 
switch is OFF, then the averaged reading is to be 
tested and displayed. The averaged reading is con- 


verted to BCD and then a test is performed to | 


determine whether the reading is to be compared 
with the upper and lower limits. 


ELSE 
70 2 DO; 
HA CALL BINTOBCD; 
72 3 IF (SWT$FLG AND ENABLE$ALARM) = ENABLE$ALARM THEN 


The reading is compared with both the upper and 
lower limits if the alarms have been enabled. The 
results of the tests are used to set and reset the 
corresponding alarm output bits. 


73. 3 DO; 

TH 4 IF READING < LIMIT(O) THEN 

7% 4 OUTPUT(CWR) = SET$ALARM$LO; 
ELSE 

76 064 QUTPUT(CWR) = RESET$ALARM$LO; 

7 4 IF READING > LIMIT(1) THEN 

78 4 OUTPUT(CWR) = SET$ALARM$HI; 

LSE 
9 OY OUTPUT(CWR) = RESET$ALARM$HI; 
80 4 END; 


If the alarms are not enabled, both the alarms are 
reset to the “‘off’’ condition. 


ELSE 
B13 CALL RESET$ALARMS ; 
3 . END; 


83. 2 END UPDATE; 


Main Program. The main program is shown below. 
Its purpose is to initialize the system and then to 
cycle, continuously executing the code previously 
described. 


/HAeaHeE Ee 
MAIN$PROGRAM: 
HHEREE ERE EEE 

byt CALL INIT; 

8 DO FOREVER; 


86 2 ACCUM$RDNG = ACCUM$RDNG + READING; 

87 2 IF UPDATE$COUNT = 0 THEN 

88 2 CALL UPDATE; 

ELSE 

89 2 UPDATE$COUNT = UPDATES$COUNT - 1; 

90 2 CALL DISPLAY$UPDATE; 

91 2 CALL TIME(4O); 

92. 2 READING = ATOD; 

93 2 END; 

94 END; 
SUMMARY/CONCLUSIONS | 


The goal of this application example is to demon- 
strate some of the common functions required for 
process control systems. Rather than show a small 
portion of a larger, more complex problem, this 
example was chosen because it presents a complete 
solution to a smaller problem. In summary, refresh- 
ing a multiplexed display was shown. Conversion 


procedures for binary to BCD and BCD to binary 


were used. A simple technique, in terms of hard- 
ware requirements, was used to enter lower and 
upper test values. And, limits testing was done, 
providing alarm indicators. 
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1/0 DEVICE CONTROLLER 


Peripheral processors have become common ele- 
ments in computer systems of all sizes and capa- 
bilities. The purpose of such a processor is to 
relieve a central processor from the burden of 
handling I/O devices. In effect, it is a form of 
distributed processing. The iSBC 80/10A can be 
used as a peripheral processor and/or as an I/O 
device controller. In such a capacity it can signifi- 
cantly reduce the amount of hardware required to 
interface peripherals. Because the iSBC 80/10A 
controls only I/O, it is of little consequence that 
it must do a great deal of detail work that other- 
wise wastes the processing capability of a larger 
central processor. 


Consider the activity of producing a listing on a 
line printer. The overhead in maintaining a pro- 
gram in the queue of a central processor which is 
producing data for a line printer can. seriously 
impact system throughput. If, however, the pro- 
gram were to send the list to a disk file and then 
command a peripheral processor to take care of the 
printing, a significant improvement in system 
performance may be achieved. Printers represent 
one example of a large number of I/O devices that 
can be controlled by an iSBC 80/10A. Other 
devices include cassettes, magnetic tape drives, 
paper tape readers and punches, etc. | 


Character Printer Controller Application Example 


The control of a Centronics 306 character printer 
is used as an I/O device controller application 
example. This example shows the interrupt capa- 
bility of mode | 8255 operation. A block diagram 
of the printer controller is shown in Figure 10 and 
a schematic in Figure 11. 


Table 2. Printer Software Control Block 


CENTRONICS. 
iSBC 80/10A PRINTER 


PORT 1(A) . 


CONTROL 


Figure 10. Printer Controller Block Diagram 


When the mode | or mode 2 configuration is used, 
software is generally required to support interrupts 
used in conjunction with handshaking operations. 
Software routines written for an interrupt driven 
environment tend to be more complex than status 
driven routines. The added complexity is because 
interrupt-driven systems are constructed such that 
other software tasks are run while the I/O transac- 
tion is in progress. A software routine that controls 
a peripheral device is generally referred to as a 
device driver. One method of implementing an 
interrupt-driven device driver is to partition the 
device driver into a “command processor” and an 
“interrupt service routine.” The command proces- 
sor is the module that validates and initiates user 
program requests to the device driver. A common 
method of passing information between the various 
software programs is to have the requesting routine 


. provide a device control block in memory. The 


device control block used in this application 
example is shown in Table 2. 


p NAME POSITION DEFINITION 


Status A 1-byte field which defines the completion status of an I/O. 


00 = Good completion 
01 = Error — command already in progress. 


Buffer Address Byte 1,2 
Byte 3° 


| Byte 4 


Character Count 


Character 


Transferred Count 
Completion Byte 5, 6 


Address performed. 


_ Pointer to the start of the data to print. 


Count of the number of characters to print. 


The number of characters transferred. 


Address of a user supplied routine which will be called after the 1/O has been 
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The command processor validates the transaction 
and initiates the operation described by the control 
block. Control is then returned to the requester 
so that other processing may proceed. The inter- 
rupt service routine processes the remainder of the 
transaction. 


Interrupt Service Routine Requirements. ‘The 
interrupt service routine requires the following 
functions: 


1. The state of the machine (registers, status, 
etc.) must be saved so that it may be re- 
stored after the interrupt is processed. 


2. The source of the interrupt must be deter- 
mined. The hardware may support a register 
which indicates the interrupting device, or 
the software may poll the device status 
registers. 


3. Data must be passed to or from the device. 


Control must be passed to the requesting 
routine at the completion of the I/O. 


5. The state of the machine must be restored 
before returning to the interrupted program. 


Printer Controller Program. The software for this | 


application has been coded using Intel® 8080 
Macro Assembly Language. 


I/O DEVICE CONTROLLER APPLICATION 
INTERRUPT DRIVEN. 


0 
1 
2 
3 
4 
5 
6 é 
7 CHARACTER PRINTER 
8 , 

9 


The following program equates are used to allow 


symbolic reference to the 8255 ports. 


it will support mode | operation. 


10 ; 

11; Httee 

l2 ; PROGRAM EQUATES 

13 peat 

14 PORTA EQU OE4H ; 8255 PORT A 

15 PORTB EQU UE5H ; 8255 PORT B 

16 PORTC EQU OE6H ; 8255 PORT C 

17 CWR EQU OE7H ; 8255 CONTROL WORD REGISTER 


An initialization control word sent to the control 
word register of the 8255 will set up the desired 
configuration. 


errr eg 
INITIALIZATION CONTROL WORD 


; 
; 
; 
; 
; 
23 5 
; 
; 
; 
; 
; 


USED TO CONFIGURE THE 8255 AS FOLLOWS: 
24 
25 PORT A - OUTPUT MODE 1 
26 PORT B - INPUT MODE O (NOT USED) 
27 PORT C LOWER - OUTPUT ~ 
28 
29 ;HakRE 
30 ICW EQU 10101010B ; INITIALIZATION CONTROL WORD 
31; eteee 


Group #1 
8255 on the iSBC 80/10A has been used because 
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The bit set/reset capability of the 8255 is used to 
control the strobe to the printer and to enable/ 
disable interrupts from the 8255. 


SET/RESET CONTROL WORDS 


34 STBON EQU 00000001B- ; SET STROBE 

35 STBOF EQU 000000008 ; RESET STROBE 

36; RRRRR ‘ > ‘ 

i 8255 ENABLE/DISABLE INTERRUPT CONTROL WORDS | 
3G; #HREH : 

39 IEN EQU . 00001101B, ; ENABLE INTERRUPTS 
40 IDN EQU - Q0001T008B » ; DISABLE INTERRUPTS 
4] 5 RRR 


Device status, control block, 


| and completion 
equates are shown below. 3 ay 


2; DEVICE S?ATUS EQUATES 
43; #keEE 
44 LPBSY EQU. O80H ° ; BUFFER FULL (LINE PRINTER BUSY) 


45 INTRA EQU 08H ; INTERRUPT REQUEST 

ALLL 

47 ; CONTROL BLOCK EQUATES 

YQ ; #eRRE 

49 CBST EQU OOH .- 3; STATUS BYTE : 

50 CBUF EQU O1H ; BUFFER ADDRESS 

51 CBCC EQU 03H ; CHARACTER COUNT 

52 CBCT EQU O4H ; CHARACTER TRANSFERED COUNT 
53 CBCMP &QU 05H ; COMPLETION SERVICE ADDRESS 
Sy jeeeee 
53 COMPLETION STATUS EQUATES 

56: tee 

57 STGD EQU 00H ; GOOD COMPLETION 

58 STE1 EQU 01H ; ERROR - COMMAND ALREADY IN PROGRESS 

59 ;tteee 


There are two origin statements in this program. 
The first origin at 38 hexadecimal is the entry 
point used when an interrupt iS generated by the 
8255. A jump instruction to the printer interrupt 
routine is stored at that location. The second 
origin at 3000 hexadecimal is the address where 
the rest of the code will be located. 


60 ; RESTART 7 ENTRY POINT. 
61 ;eeeRR 

62. - ORG 0038H 

63 JMP PINT 

64 .eeRHE 

65 ; PROGRAM ORIGIN 

66 ;eeeeE 

67 ORG 3000H 

68 ; #teRH 


An initialization subroutine issues the mode ¢ con- 
trol word to the 8255 control word register after 
reset of the device. The printer strobe must then be 
disabled. 


69 ; 

70 ; INITIALIZATION ROUTINE 

71 3 

T2 ; A,H,L REGISTERS MODIFIED 

73 ; 

Ty #eeeH 

75 INIT: 

76 MVI A,ICW ; GET MODE CONTROL WORD 

17 OUT CWR. ; OUTPUT TO CONTROL WORD REGISTER 
78 MVI A,STBON ; GET SET DATA STROBE CONTROL WORD 
79 OUT CWR ; SET DATA STROBE (LOW TRUE SIGNAL) 
80 RET ; RETURN TO CALLER 


The command processor is started by the user 
routine through a subroutine call to PSTRT, with 
the address of the control block in the D and E 
registers. The command processor insures that an 
I/O operation is not already in progress, starts the 
I/O, enables interrupts, and returns to the caller so 
that other processing may proceed. 
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The flowchart and listing for the command proces- 
sor are shown below. 


PSTRT 


YES 


COMMAND 


ERROR 
POST TO 
USER 


ENABLE 
PROCESSOR 
INTERRUPTS 


RETURN 


82 
83 alahahalel 
84 ; 
85 ; COMMAND PROCESSOR 
’ 
87 ; INPUTS: CONTROL BLOCK ADDRESS IN D AND E REGISTERS 
88 ; 
89 ; OUTPUTS: START I/O OR ERROR STATUS IN CONTROL BLOCK 
90 ; 
91 ; A,H,L REGISTERS MODIFIED 
92 b} 
93 j BREE 
94 PSTRT: 
95 LDA PIPRG+1 ; GET PRINT IN PROGRESS BLOCK ADDRESS 
96 ANA A ; SEE IF ZERO (PRINT IN PROGRESS) 
97 ; IF BLOCK ADDRESS NOT EQUAL TO ZERO THEN 
98 ; PRINT IN PROGRESS 
99 JNZ PSTE  ; IF YES - BRANCH TO ERROR 
100 XCHG 
101 SHLD PIPRG ; SAVE-CONTROL BLOCK ADDRESS 
102 XCHG 
103 LXI H,CBCT ; GET INDEX TO CT 
104 DAD ; COMPUTE ADDRESS OF CT 
105 MVI M,OOH  ; CLEAR CT 
106 CALL PDATA —; START I/O 
107 EI ; ENABLE PROCESSOR INTERRUPTS 
108 RET ; RETURN TO CALLER 
109 ;###e# 
110 ; ERROR - TRANSACTION ALREADY IN PROGRESS 
111 5 ities 
112 PSTE: 
113 MVI A,STE1 ; GET ERROR STATUS CODE 
114 JMP POST  ; PASS CONTROL TO COMPLETION ROUTINE 
115 


Interrupt Processing. When the 8255 generates an 
interrupt, the interrupt request is serviced by the 
SO80A CPU. The CPU disables processor interrupts 
and then executes the instruction at location 38 
hexadecimal, which is a jump to the interrupt 
service routine. The interrupt service routine saves 
the processor state and polls the 8255 to determine 
the source of the interrupt. Once the interrupting 
device is identified, the printer output data routine 
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is called. After the entire buffer has been printed, 
the interrupt service routine passes control to the 
user-supplied completion routine. Before returning 
from the interrupt, the state of the processor is 
restored. | 


There are a number of error conditions which may 
occur, such as an interrupt from a device that does 
not have an active control block, or an interrupt 
when polling establishes that no device requires 
service. Neither of these errors should occur, but if 
they do, the driver should perform in a consistent 
fashion. The recovery routines implemented to 
handle these interrupt error conditions are deter- 
mined by the environment of the particular appli- 
cation. | 


The flowchart and listing for the printer interrupt 
service routine are shown below. 


INT 7 


SAVE 
REGISTERS 


DISABLE 8255 
INT ENABLE 
PROCESSOR 

INTERRUPTS 


POLL 
OTHERS & 
PROCESS 


RESTORE 
REGISTERS 


ENABLE 
PROCESSOR 
INTERRUPTS 


RETURN 


116 . 

117 5 feat 

118 ; PRINTER iNTERRUPT SERVICE ROUTINE 

119 ; ALL REGISTERS SAVED AND RESTORED 

120 ;ewiee 

121 PINT: 

122 PUSH PSW ; SAVE PSW 

123 PUSH B ; SAVE REGISTER PAIR B AND C 
_ 124 “PUSH D ; SAVE REGISTER PAIR D AND & 

25 PUSH H ; SAVE REGISTER PAIR H AND L 

126 ;#ReH 
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le7 ; POLL INTERRUPT SOURCE - SEE OF 8255 

128 ;teeee : 

129 IN PORTC ; GET STATUS OF DEVICE 

130° ANI INTRA ; SEE IF INT 

131 JZ: PPOLL NO -BRANCH TO POLL OTHER DEVICES IF ANY 
132 MVI- A,IDN  ; GET 8255 INT DISABLE CONTROL WORD 
133 OUT CWR ; DISABLE DEVICE INTERRUPTS 

134 EI - ‘".3 ENABLE, PROCESSOR INTERRUPTS . , 
135 LHLD PIPRG ; GET CONTROL BLOCK ADDRESS 

136 XRA A ; CLEAR A REG 

137 CMP H ; SEE IF PRINT IN PROGRESS 

138 JZ PIER1 ; NO - BRANCH TO ERROR ROUTINE 
139 XCHG. .. 

140 CALL PDATA; PRINT DATA 

141.1 Rite 

142 RESTORE REGISTERS AND RETURN FROM INTERRUPT 

143; tesa 

144 PRIN: ‘ 

145 _ POP H ; RESTORE REGISTER PAIR H AND L 
146 POP §=D - 3 RESTORE REGISTER PAIR D AND E 
147 POP B ; RESTORE REGISTER PAIR B AND Cc 
148 POP PSW ; RESTORE PSW AND A 

149 EI ; ENABLE PROCESSOR INTERRUPTS 
150 - RET ; RETURN TO INTERRUPTED PROCESS 
151; tiie 

152 ; POLL OTHER DEVICES IF ANY 

153 ; IF NO OTHER DIVICES TO POLL - USER SUPPLIED ERROR 
154 ; RECOVERY ROUTINE. 

155 ; tame 

156 PPOLL: ; 

197 JMP PRIN ; RETURN 

158 ;eeeeH 

159 ; ERROR - INTERRUPT FROM IDLE DEVICE 

160 ; USER SUPPLIED ERROR RECOVERY ROUTINE 
161; eee 

162 PIER1: ; 

163 JMP PRIN ; RETURN 

164 


The printer output data routine places a character 
in the output buffer of the 8255. Data in the 
control block is used to direct the transfer of a 
character. A data strobe signal is then generated 
through the use of the port C bit set/reset feature. 


The flowchart and listing for the printer output 
data routine are shown below. 


DISABLE 
PROCESSOR 
INTERRUPTS 


ENABLE 8255 
INTERRUPTS 


RETURN 


UPDATE 
CT : 


GOOD COMP 
STORE 
STATUS 


POST TO 
USER 


GET CHAR 


OUTPUT 
CHARACTER 
GENERATE 
STROBE 


RETURN 


. 165 
* 166 
167 
168 
169 
170 
171 
172 
173 
174 
175 
176 
177 
178 
179 
180 
181 
182 
183 
184 
185 
186 
187 
188 
189 
190 
191 
192 
193 
194 
195 
196 
197 


198 |. 


199 
200 
201 


PRINTER OUTPUT DATA. ROUTINE 


CONTROL BLOCK ADDRESS IN D AND E REG 


IN PORTC ; GET STATUS OF DEVICE 
ANI LPBSY ; SEE IF BUSY (BUFFER FULL) 

JZ PD10 —«;_: IF BUSY - BRANCH 

LXI H,CBCT ; GET INDEX TO CT 

DAD =D . 3; COMPUTER ADDRESS OF CT 

MOV AM ; GET CT 

INR MM ; INC CT 

DCX 4H ; DEC TO CC 

(MPM ; SEE IF EQUAL 

Bis PCOMP ; IF EQUAL - DONE GO TELL USER 

-LXI H,CBUF ; GET INDEX TO BUFFER ADDRESS 

DAD D ; COMPUTE ADDRESS OF BUFFER ADDRESS 
PUSH =D ; SAVE D AND E REGISTERS 

MOV EM ; GET LSB OF BUFFER ADDRESS 

INX’ 4H ; INC TO NEXT BYTE 

MOV D,M ; GET BUFFER MSB 

MVI H,OOH =; CLEAR H REG 

MOV Lek ; GET CT a 

DAD ° D ; COMPUTER CHARACTER ADDRESS 

MOV A,M ; GET CHARACTER 

OUT PORTA ; OUTPUT CHARACTER TO PRINTER 

MVI A,STBOF ; RESET DATA STROBE (LOW TRUE SIGNAL) 
OUT —CWR 

INR A ; GENERATE SET CONTROL WORD 

OUT CWR ; SET DATA STROBE 

POP. =D ; RESTORE CONTROL BLOCK ADDRESS 

JMP PDATA ; LOOP UNTIL BUSY 


If the printer is busy at the time the printer output 
routine is called, a printer busy routine is executed. 
The printer busy routine disables’ the processor 
interrupts, enables the 8255. interrupts and then 
enables the processor interrupts on its return to 
the caller. 


PRINTER BUSY - RETURN 


A, IEN 
CWR 


; DISABLE INTERRUPTS 


: SET INTERRUPT ENABLE 


’ 


; RETURN TO CALLER 


’ 


ENABLE DEVICE INTERRUPTS 


When the printer output routine has exhausted the 
data from the buffer, a good status code is posted 
to the user. The command in Progress flag is also 


cleared. 
211 5 aie 
212 ; 
213; HeRER 
214 PCOMP: ; 
215 MVI ‘ 
216 CALL 
217 XRA 
218 STA 
219 RET 
220 


A, STGD 
POST 

A 
PIPRG+1 


POST GOOD ‘COMPLETION TO USER 


GET GOOD STATUS CODE 

POST TO USER 

CLEAR A REG 

CLEAR COMMAND IN PROGRESS ADDRESS 
RETURN TO CALLER 


The post to user completion routine obtains the 
completion address from the device control block 
and passes control to the user routine. 


221, 


222 3 


- 223 
2244 
225 


396. 


227 


228 - 


229 
230 
231 


232° 


233 
. 234 
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POST TO USER ' COMPLETION ROUTINE 


INPUTS: 


OUTPUTS: 


STATUS CODE IN A REG 

CONTROL BLOCK ADDRESS IN D AND E REG 
PASSES CONTROL TO USER: COMPLETION ADDRES, 
SPECIFIED IN CONTROL BLOCK 


‘WITH CONTROL BLOCK ADDRESS IN D AND E RE 


A,H,L,B,C REG MODIFIED 
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235 POST: 
236 


M, A. ; UPDATE STATUS 
238 XCHG 
239 LXI H,CBCMP ; GET INDEX TO COMPLETION ADDRESS 
240 DAD D ; COMPUTE ADDRESS 
24 MOV CM ; GET LSB OF COMPLETION ADDRESS 
242 INX H ; INC TO NEXT BYTE 
243 MOV BM 3; GET MSB OF COMPLETION ADDRESS 
Quy PUSH B ; PUSH ADDRESS ON STACK 
245 RET ; PASS CONTROL TO USER ROUTINE 
246 ;aeeee 
247 ; DATA AND TABLES 
2U8 ; eReE 
249 ORG 3D00H 
250 PIPRG: DW 0 ; IN PROGRESS CONTROL BLOCK ADDRESS 
251 ; IF DATA = 0 NO CONTROL BLOCK IN PROGRESS 
252 ; IF DATA <> 0 CONTROL BLOCK IN PROGRESS 
253 ;ateee 
254 ; END OF MODE ONE EXAMPLE 
255 ;#eee 
256 END 
SUMMARY/CONCLUSIONS 


The iSBC 80/10A has the capability to function in 
the capacity of a peripheral processor and/or a 
device controller. This capability is provided in 
part by the interrupt support logic accompanying 
the parallel I/O ports. This application example 
shows how the iSBC 80/10A requires only an inter- 


connect to the device to be controlled. 


CONCLUSION 


The purpose of this application note has been to 
expose the reader to a broad spectrum of potential 
applications of the Intel iSBC 80/10A and System 
80/10 products. Applications have been presented 
in the areas of instrumentation, communication, 
process control and I/O device control. The exam- 
ples were limited to short problems that could be 
completely described. 


Intel’s PL/M-80 and 8080 Macro Assembly Lan- 
guage were both used in the examples. Instead of 
using only assembly language, it was felt that 
PL/M-80 should also be shown. Coding in an 
algorithmic language is generally more natural than 
assembly language and provides these added bene- 
fits: reduced program development time and cost, 
improved product reliability, and easier program 
maintenance. 
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Figure 11. Printer Controller Schematic 
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While the task of actually configuring the SBC 
80/10 for the applications has not been described 
in this note, detailed instructions are contained in 
the tables of Chapter 4 in theiSBC 80/10 and iSBC 
S80/10A Single Board Computer Hardware Refer- 
ence Manual. 


The Intel iSBC 80/10A has been designed to pro- 
vide users with subsystems that have processing 
power, memory storage, parallel and serial pro- 
grammable I/O interfaces. A design goal of the 
iSBC 80/10A was to minimize the requirements 
for customized interface hardware in user applica- 
tions. This application note has demonstrated the 
achievement of this goal. The net effect is to 
reduce the number of tedious design tasks, thus 
allowing the systems designer to concentrate on 
systems integration and other problems unique 
to his job. 
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I. INTRODUCTION 


A significant measure of the power and flexibility 
of the Intel OEM Computer Product Line can be 
attributed to the design of the Intel MULTIBUS 
system bus. The bus structure provides a common 
element for communication between a wide 
variety of system modules which include: Single 
Board Computers, memory, digital, and analog 
I/O expansion boards, and peripheral controllers. 


The purpose of this application note is to help you 
develop a working knowledge of the Intel MULTI- 
BUS specification. This knowledge is essential for 
configuring a system containing multiple mod- 
ules. Another purpose is to provide you with the 
information necessary to design a bus interface for 
a slave module. One of the tools that will be used to 
achieve this goal is the complete description of a 
MULTIBUS slave design example. Other portions 
of this application note provide an in depth 
examination of the bus signals, operating charac- 
teristics, and bus interface circuits. 


This application note was originally written in 
1977. Since 1977, the MULTIBUS specification 
has been significantly expanded to cover opera- 
tion with both 8 and 16-bit system modules and 
with an auxiliary power bus. This application 
note now contains information on these new 
MULTIBUS specification features. 


In addition, a detailed MULTIBUS specification 
has also been published which provides the user 
with further information concerning MULTIBUS 
interfacing. The MULTIBUS specification and 
other useful documents are listed in the overleaf of 
this note under Related Intel Publications. 


Il. MULTIBUS™ SYSTEM BUS 
DESCRIPTION 


Overview 


The Intel MULTIBUS signal lines can be grouped 
in the following categories: 20 address lines, 16 
bidirectional data lines, 8 multilevel interrupt 
lines, and several bus control, timing and power 
supply lines. The address and data lines are 
driven by three-state devices, while the interrupt 
and some other control lines are open-collector 
driven. 


Modules that use the MULTIBUS system bus have 
a master-slave relationship. A bus master module 
can drive the command and address lines: it can 
control the bus. A Single Board Computer is an 
example of a bus master. A bus slave cannot 
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control the bus. Memory and I/O expansion 
boards are examples of bus slaves. The MULTI- 
BUS architecture provides for both 8 and 16-bit 
bus masters and slaves. 


Notice that a system may have a number of bus 
masters. Bus arbitration results when more than 
one master requests control of the bus at the same 
time. A bus clock is usually provided by one of the 
bus masters and may be derived independently 
from the processor clock. The bus clock provides a 
timing reference for resolving bus contention 
among multiple requests from bus masters. For 
example, a processor and a DMA (direct memory 
access) module may both request control of the 
bus. This feature allows different speed masters to 
share resources on the same bus. Actual transfers 
via the bus, however, proceed asynchronously 
with respect to the bus clock. Thus, the transfer 
speed is dependent on the transmitting and 
receiving devices only. The bus design prevents 
slow master modules from being handicapped in 
their attempts to gain control of the bus, but does 
not restrict the speed at which faster modules can 
transfer data via the same bus. Once a bus request 
is granted, single or multiple read/write transfers 
can proceed. The most obvious applications for the 
master-slave capabilities of the bus are multi- 
processor configurations and high-speed direct- 
memory-access (DMA) operations. However, the 
master-slave capabilities of the bus are by no 
means limited to these two applications. 


MULTIBUS™ Signal Descriptions 


This section defines the signal lines that comprise 
the Intel MULTIBUS system bus. These signals 
are contained on either the P1 or P2 connector of 
boards compatible with the MULTIBUS specifi- 
cation. The P1 signal lines contain the address, 
data, bus control, bus exchange, interrupt and 
power supply lines. The P2 signal lines contain the 
optional auxiliary signal lines. Most signals on 
the bus are active-low. For example, a low level on 
a control signal on the bus indicates active, whilea 
low level on an address or data signal on the bus 
represents logic “1” value. 


NOTE 


In this application note, a signal will be 
designated active-low by placing a slash (/) 
after the mnemonic for the signal. 


Appendix A contains a pin assignment list of the 
following signals: | . ; 
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MULTIBUS P1 Signal Lines — | 
Initialization Signal Line _ 


INIT/ 


Initialization signal; resets the entire system to 
a known internal state. INIT/ may be driven by 
one of the bus masters or by an external source 
such as a front panel reset switch. 


Ad dveds- and Tahini Lies 


ADR0O/ - ADR13/ 


20 address lines; used to transmit the address of 
the memory location or I/O port to be accessed. 
The lines are labeled ADRO/ through ADR9Y/, 
ADRA/ through ADRF/ and ADR10/ through 
ADR13/. ADR13/ is the most significant bit. 
8-bit masters. use 16 address lines (ADRO/ - 
ADRF’/) for memory addressing and 8 address 
lines (ADRO/ - ADR7/) for I/O port: selection. 
16-bit masters use all twenty address lines for 
memory addressing and 12 address lines 
(ADRO/ - ADRB/).for I/O port selection. Thus, 
8-bit masters may address 64K bytes of memory 
and 256 I/O devices while 16-bit masters may 
address 1 megabyte of memory and 4096 I/O 
devices. (The 8086 CPU actually permits 16 
address bits to be used to specify I/O devices, 
the MULTIBUS specification, however, states 
that only the low order 12 address bits can be 
used to specify I/O ports.) In a 16-bit system, 
the ADRO0/ line is used to indicate whether alow 
(even) byte or a high (odd) byte of memory or 
I/O space is being accessed in a word oriented 
memory or I/O device. 


BHEN/ 


Byte High Enable; the sdivess Santa ine 
which is used to specify that data will be trans- 


ferred on the high byte (DAT8/ - DATF/) of the. 


MULTIBUS data lines. With current iSBC 
boards, this signal effectively specifies that a 
word (two byte) transfer is to be performed. This 
signal is used only in systems which incorporate 
sixteen bit memory or I/O modules. 


INH1/ 


Inhibit RAM signal; prevents RAM memory 
devices from responding to the memory address 
on the system address bus. INH1/ effectively 
allows ROM memory devices to override RAM 
devices when ROM and RAM memory are 
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assigned the same memory addresses. INH1/ 
may also be used to allow memory mapped I/ : 
devices to override RAM memory. . 


INH2/ 


Inhibit ROM signal, prevents ROM memory. 
devices from responding to the memory address. 
on the system address bus. INH2/ effectively. 
allows auxiliary ROM (e.g., a bootstrap pro- 
gram) to override ROM devices when ROM and 
auxiliary ROM memory are assigned the same 
memory addresses. INH2/ may also be used to 
allow memory mapped I/O devices to Ee 
ROM memory. 


Data Lines 


DATO/ - DATF/ 


16 bidirectional data lines; used to erin or 
receive information to or from a memory loca- 

tion or I/O port. DATF’/ being the most signifi- 
cant bit. In 8-bit systems, only lines DATO/ - 
DAT7/ are used (DAT7/ being the most signi- 
ficant bit). In 16-bit systems, either 8 or 16 lines 
may be used for data transmission. 


Bus Priority Resolution Lines 


BCLK/ 


Bus clock; the negative edge (high to low) of 
BCLK/ is used to synchronize bus priority re- 
solution circuits. BCLK/ is asynchronous to the 
CPU clock. It has a100 ns minimum period and 
a 35% to 65% duty cycle. BCLK/ may be slowed, 
stopped, or single stepped for debugging. 


CCLK/ 


Constant clock; a bus signal which provides a 
clock signal of constant frequency for unspeci- 
fied general use by modules on the system bus. 
CCLK/ has a minimum period of 100 ns and a 
35% to 65% duty Noe 


BPRN/ 


Bus priority in signal; indicates to a particular 
master module that no higher priority module. 
is requesting use of the system bus. BPRN/ is 
synchronized with BCLK/. This signal is. not 
bused on the backplane. = 
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BPRO/ 


Bus priority out signal; used with serial (daisy 
chain) bus priority resolution schemes. BPRO/ 
is passed to the BPRN/ input of the master 
module with the next lower bus priority. BPRO/ 
is synchronized with BCLK/. This signal is not 
bused on the backplane. 


BUSY/ 


Bus busy signal; an open collector line driven 
by the bus master currently in control to indicate 
that the bus is currently in use. BUSY/ prevents 


all other master modules from gaining control - 


of the bus. BUSY/ is synchronized with BCLK/. 


BREQ/ 


Bus request signal; used with a parallel bus 
priority network to indicate that a particular 
master module requires use of the bus for one 
or more data transfers. BREQ/ is synchronized 
with BCLK/. This signal is not bused on the 
backplane. 


CBRQ/ 


Common bus request; an open-collector line 
which is driven by all potential bus masters 
and is used to inform the current bus master 
that another master wishes to use the bus. If 
CBRQ/ is high, it indicates to the bus master 
that no other master is requesting the bus, and 
therefore, the present bus master can retain the 
bus. This saves the bus exchange overhead for 
the current master. 


Information Transfer Protocol Lines 


A bus master provides separate read/write 
command signals for memory and I/O devices: 
MRDC/, MWTC/, IORC/ and IOWC/, as ex- 
plained below. When a read/write command is 
active, the address signals must be stabilized at all 
slaves on the bus. For this reason, the protocol 
requires that a bus master must issue address 
signals (and data signals for a write operation) at 
least 50 ns ahead of issuing a read/write command 
to the bus, initiating the data transfer. The bus 
master must keep address signals unchanged until 
at least 50 ns after the read/write command is 
turned off, terminating the data transfer. 


A bus slave must provide an acknowledge signal to 


the bus master in response to a read or write 
command signal. 


MRDC/ 


Memory read command; indicates that the 
address of a memory location has been placed 
on the system address lines and specifies that 
the contents (8 or 16 bits) of the addressed 
location are to be read and placed on the system 
data bus. MRDC/ is asynchronous with respect 
to BCLK/. 


MWTC/ 


Memory write command; indicates that the 
address of a memory location has been placed 
on the system address lines and that data (8 or 
16 bits) has been placed on the system data bus. 
MWTC/ specifies that the data is to be written 
into the addressed memory location. MWTC/ is 
asynchronous with respect to BCLK/. 


IORC/ 


I/O read command; indicates that the address 
of an input port has been placed on the system 
address bus and that the data (8 or 16 bits) at 
that input port is to be read and placed on the 
system data bus. IORC/ is asynchronous with 
respect to BCLK/. 


IOWC/ 


I/O write command; indicates that the address 
of an output port has been placed on the system 
address bus and that the contents of the system 
data bus (8 or 16 bits) are to be output to the 
address port. IOWC/ is asynchronous with 
respect to BCLK/. 


XACK/ 


Transfer acknowledge signal, the required 
response of a slave board which indicates that 
the specified read/write operation has been 
completed. That is, data has been placed on, or 
accepted from, the system data bus lines. 
XACK/ is asynchronous with respect to BCLK/. 


Asynchronous Interrupt Lines 


INTO/ - INT7/ 


8 Multi-level, parallel interrupt request lines; 


AFN-01931A 


used ‘with a parallel interrupt resolution: net-. 


work. INTO/ has the highest priority, while 
INT7/ has lowest priority. Interrupt lines 


should be driven with open collector drivers. | 4 


INTA/ 


Interrupt acknowledge; an interrupt acknowl- 
edge line (INTA/), driven by the bus master, 
requests the transfer of interrupt information 


onto the bus from slave priority interrupt con-. 


trollers (8259s or 8259As). The specific informa- 
tion timed onto the bus depends upon the 
implementation of the interrupt scheme. In 
general, the leading edge of INTA/ indicates 
that the address bus is active while the trailing 
edge indicates that data is present on the data 
lines. 


MULTIBUS P2 Signal Lines — The signals 
contained on the MULTIBUS P2 auxiliary con- 
nector are used primarily by optional power 
back-up circuitry for memory protection. 
signals are not bused on the backplane, and 
therefore, require a separate connector for each 
board using the P2 signals. Present iSBC boards 
have a slot in the card edge and should be used 
with a keyed P2 edge connector. Use of the P2 
signal lines is optional. | 3 | 


ACLO 

AC Lou; this signal generated by the power 
supply goes high when the AC line voltage 
drops below a certain voltage (e.g., 108v AC in 
115v AC line voltage systems) indicating D.C. 
power will fail in 3 msec. ACLO goes low when 
all D.C. voltages return to approximately 95% 
of the regulated value. This line must be pulled 
up by the optional standby power source, if one 
is used. 


PFIN/— — 2 

_ Power fail interrupt; this signal interrupts the 
processor when a.power failure occurs, it is 
driven by external power fail circuitry. 


PFSN/ 


Power fail sense; this line is the output of a 
latch which indicates that a power failure has 
occurred. It is reset by PFSR/. The power fail 


P2 
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sense latch is part of external power fail cir- 
cuitry and must be powered. by the Standby 
_ power source. 


PFSR/ 


Power fei sense reset; this line i is used to reset 
the power fail sense latch (PFSN/). 


MPRO/ 


Memory. gee: prevents memory operation 
during period of uncertain DC power, by in- 
hibiting memory requests. MPRO/ is driven 
by external power fail circuitry. 


ALE 


Address latch enable; generated by the CPU 
— (8085 or 8086) to provide an auxiliary address 
~ latch. 


HALT/ 2 
Halt; indicates that the master CPU is halted. 


AUX RESET/ 


Auxiliary Reade this Seieatale ganeitind sig- 
_ nal initiates a power-up sequence. - 


WAIT) 


Bus master wait state; this signal Gudiegies 
that the processor is in a wait state. 


Reserved — Several P1 and P2 connector bus 
pins are unused. However, they should be regard- 
ed as reserved for dedicated use in future Intel 
products. | * 


Power Supplies — The power supply bus pins 
are detailed in Appendix: A which -contains the 
pin assignment of ener on a era 
ine ea 


It is the designer’ S responsibility to provide 
adequate bulk decoupling on the board to avoid 
current surges on the power supply lines. Itis also 
recommended ‘that you provide high frequency 
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decoupling for the logic on your board. Values of 
22uF for +5v and +12v pins and 10uF for -5v and 
-12v pins are typical on iSBC boards. 


Operating Characteristics 


Beyond the definition of the MULTIBUS signals 
themselves, it is important to examine the 
operating characteristics of the bus. The AC 
requirements outline the timing of the bus signals 
and in particular, define the relationships between 
the various bus signals. On the other hand, the DC 
requirements specify the bus driver character- 
istics, maximum bus loading per board, and the 
pull-up/down resistors. 


The AC requirements are best presented by a 
discussion of the relevant timing diagrams. 
Appendix B contains a list of the MULTIBUS 
timing specifications. The following sections will 
discuss data transfers, inhibit operations, inter- 
rupt operations, MULTIBUS multi-master opera- 
tion and power fail considerations. 


Data Transfers — Data transfers on the MULTI- 
BUS system bus occur with a maximum band- 
width of 5 MHz for single or multiple read/write 
transfers. Due to bus arbitration: and memory 
access time, a typical maximum transfer rate is 
often on the order of 2 MHz. 


Read Data 


Figure 1 shows the read operation AC timing 
diagram. The address must be stable (tas) fora 
minimum of 50 ns before command (IORC/ or 
MRDC/). This time is typically used by the bus 
interface to decode the address and thus provide 
the required device selects. The device selects 
establish the data paths on the user system in 
anticipation of the strobe signal (command) 
which will follow. The minimum command pulse 
width is 100 ns. The address must remain stable 
for at least 50 ns following the command (t Aq). 
Valid data should not be driven onto the bus prior 
to command, and must not be removed until the 
command is cleared. The XACK/ signal, which is 
a response indicating the specified read/ write 
operation has been completed, must coincide or 
follow both the read access and valid data (tpx)- 


XACK/ must be held until the command is cleared 


(tXAH). | . 


IORC/ 


or 
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MASTER 
50NS miN—>| 


STABLE 
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<= ~e 'XAH}> 
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MASTER 
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Figure 1. Read AC Timing 


Write Data 


The write operation AC timing diagram is shown 
in Figure 2. During a write data transfer, valid 
data must be presented simultaneously with a 
stable address. Thus, the write data setup time 
(tps) has the same requirement as the address 
setup time (tas). The requirement for stable data 
both before and after command (IOWC/ or 
MWTC/) enables the bus interface circuitry to 
latch data on either the leading or trailing edge of 
command. 


“ tcmD » 
| 100NS MIN | 


lOWC/ 

or 
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50NS MiN—>| tas |~- >| taH |~-50NS MIN 


ADDRESS 
LINES STABLE ADDRESS 
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STABLE © 
WRITE DATA 


MASTER 
TO 
SLAVE 


DATA 
LINES 


XACK/ 


Figure 2. Write AC Timing 


Data Byte Swapping in 16-bit Systems 


A 16-bit master may transfer data on the MULTI- 
BUS data lines using 8-bit or 16-bit paths 
depending on whether a byte or word (2 byte) 
operation has been specified. (A word transfer 
specified with an odd I/O or memory address will 
actually be executed as two single byte transfers.) 


_ An 8-bit master may only perform byte transfers 
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on the MULTIBUS data lines DATO/ - DAT’7/. | 


In order to maintain compatibility with older 
8-bit masters and slaves, a byte swapping buffer 
is included in all new 16-bit masters and 16-bit 
slaves. In the iSBC product line, all byte transfers 
will take place on the low 8 data lines DATO/ - 
DAT7/. Figure 3 contains a example of 8/16-bit 
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data driver logic for 16-bit master. and slave 
systems. In the 8/16-bit system, there are three 
sets of buffers; the lower byte buffer which 
accesses DATO/ - DAT7/, the upper byte buffer 
which accesses DAT8/ - DATF’/, and the swap 
byte buffer which accesses the MULTIBUS data 
lines DATO/ - DAT7/ and transfers the data 
to/from the on-board data bus lines D8 - DF. 


Figure 4 summarizes the 8 and 16-bit data paths 
used for three types of MULTIBUS transfers. Two 
signals control the data transfers. 


Byte High Enable (BHEN/) active indicates that 
the bus is operating in sixteen bit mode, and 
Address Bit 0 (ADR0O/) defines an even or odd byte 
transfer address. | 


On the first type of transfer, BHEN/ is inactive, 
and ADR0O/ is inactive indicating the transfer of 
an even eight: bit byte. The transfer takes place 
across data lines DATO/ - DAT7/. | 
On the second type of transfer, BHEN/ is inactive, 
and ADR0/ is active indicating the transfer of a 
high (odd) byte. On this type of transfer, the odd 
(high) byte is transferred through the Swap Byte 
Buffer to DATO/ - DAT7/. This makes eight bit 
and sixteen bit systems compatible. 


16-BIT DEVICE ~ MULTIBUS BHEN/ 
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BYTES 
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Ts ~ LOWER 
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D0-D7 ence 
DIRECTION 
SWAP 
‘BYTE 
BUFFER DATO/ 
: DATF/ 
D8-DF 


DAT8/-DATF/ 


74800 SWAP 


Bags acta - BYTE/ UPPER 
BUFFER 


° BYTE 


‘ i 
ADRO yA O | 
AEN/ ee 
74804 \/ o 
. O , 
O 
O 
Ls 


Figure 3. 8/16-Bit Data Drivers 


MULTIBUS DEVICE __ 
TRANSFER | BYTE 
DATA PATH | TRANSFERRED. 


8-BIT, 
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. 8-BIT, 
DATO/ - DAT7/ 


 16-BiT, 
DATO/ - DATF/ 


Figure 4. 8/16-Bit Device Transfer Operation 
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The third type of transfer is a 16 bit (word) 
transfer. This is indicated by BHEN/ being 
active, and ADRO/ being inactive. On this type of 
transfer, the low (even) byte is transferred on 
DATO/ - DAT7/ and the high (odd) byte is 
transferred on DAT8/ - DATF’. 

Note that the condition when both BHEN/ and 
ADRO/ are active is not used with present iSBC 
boards. This condition could be used to transfer a 
high odd byte of data on DAT8/ - DATF’, thus 
eliminating the need for the swap byte buffer. 
However, this is not a recommended transfer type, 
because it eliminates the capability of communi- 
cating with 8-bit modules. 


Inhibit Operations — Bus inhibit operations are 
required by certain bootstrap and memory mapped 
I/O configurations. The purpose of the inhibit 
operation is to allow acombination of RAM, ROM, 
or memory mapped I/O to occupy the same 
memory address space. In the case of a bootstrap, 
it may be desirable to have both ROM and RAM 
memory occupy the same address space, selecting 
ROM instead of RAM for low order memory only 
when the system is reset. A system designed to use 


ADDRESS/ 


DATA/ 


memory mapped I/O, which has actual memory 
occupying the memory mapped I/O address 
space, may need to inhibit RAM or ROM memory 
to perform its functions. 


There are two essential requirements for a success- 
ful inhibit operation. The first is that the inhibit 
signal must be asserted as soon as possible, within 
a maximum of 100 ns (tq), after stable address. 
The second requirement for a successful inhibit 
operation is that the acknowledge must be delayed 
(txACKB) to allow the inhibited slave to ter- 
minate any irreversible timing operations in- 
itiated by detection of a valid command prior to its 
inhibit. 

This situation may arise because a command can 
be asserted within 50 ns after stable address (tac) 
and yet inhibit is not required until 100 ns (typ) 
after stable address. The acknowledge delay time 
(tx ACKB) is a function of the cycle time of the 
inhibited slave memory. Inhibiting the iSBC 016 
RAM board, for example, requires a minimum of 
1.5 usec. Less time is typically needed to inhibit 
other memory modules. For example, the iSBC 104 
board requires 475 ns. | 


Figure 5 depicts a situation in which both RAM 
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DRIVER 

ENABLE/ yao 
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Figure 5. Inhibit Timing 
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and PROM memory have the same memory 
addresses. In this case, PROM inhibits RAM, 
producing the effect of PROM overriding RAM. 
After address is stable, local selects are generated 
for both the PROM and the RAM. The PROM local 
select produces the INH1/ signal which then 
removes the RAM local select and its driver enable. 
Because the slave RAM has been inhibited after it 
had already begun its cycle, the PROM XACK/ 
must be delayed (tx ACKB) until after the latest 
possible acknowledgement from the RAM 
(tX ACKA). | 


Interrupt Operations — The MULTIBUS inter- 


rupt lines INTO/ - INT7/ are used by a MULTI-. 


BUS master to receive interrupts from bus slaves, 
other bus masters or external logic such as power 
fail logic. A bus master may also contain internal 
interrupt sources which do not require the bus 
interrupt lines to interrupt the master. There are 
two interrupt implementation schemes used by 
bus interrupts, Non Bus Vectored Interrupts and 
Bus Vectored Interrupts. Non Bus Vectored 
Interrupts do not convey interrupt vector address. 


information on the bus. Bus Vectored Interrupts | 


are interrupts from slave Priority Interrupt Con- 


trollers (PICs) which do convey interrupt vector 


address information on the bus. — 


Non Bus Vectored Interrupts 

Non Bus Vectored Interrupts are those interrupts 
whose interrupt vector address is generated by the 
bus master and do not require the MULTIBUS 
address lines for transfer of the interrupt vector 
address. The interrupt vector address is generated 
by the interrupt controller on the master and 
transferred to the processor over the local bus. The 
source of the interrupt can be on the master module 
or on other bus modules, in which case the bus 
modules use the MULTIBUS interrupt request 
lines (INTO/ - INT7/) to generate their interrupt 
requests to the bus master. When an interrupt 
request line is activated, the bus master performs it 
own interrupt operation and processes the inter- 
rupt. Figure 6 shows an example of Non Bus 


- Vectored Interrupt implementation. 


Bus Vectored Interrupts 

Bus Vectored Interrupts (Figure 7) are those inter- 
rupts which transfer the interrupt vector address 
along the MULTIBUS address lines from the 
slave to the bus master using the INTA/ command 


signal for synchronization. 
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Figure 6. Non Bus Vectored Interrupt Implementation 
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Figure 7. Bus Vectored Interrupt Logic (With 2 INTA/ Timing Diagram) 


When an interrupt request from the MULTIBUS 
interrupt lines INTO/ - INT7/ occurs, the interrupt 
control logic on the bus master interrupts its 
processor. The processor on the bus master 
generates an INTA/ command which freezes the 
state of the interrupt logic on the MULTIBUS 


slaves for priority resolution. The bus master also 


locks (retains the bus between bus cycles) the 
MULTIBUS control lines to guarantee itself 
consecutive bus cycles. After the first INTA/ 
command, the bus master’s interrupt control logic 
puts an interrupt code on to the MULTIBUS 
address lines ADR8/ - ADRA/. Theinterrupt code 


is the address of the highest priority active inter-— 


rupt request line. At this point in the Bus Vectored 
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Interrupt procedure, two different sequences could 
take place. The difference occurs, because the 
MULTIBUS specification can support masters 
which generate one additional INTA/ (8086 
masters) or two additional INTA/s (8080A and 
8085 masters). 


If the bus master generates one additional INTA/, 
this second INTA/ causes the bus slave interrupt 
control logic to transmit an interrupt vector 8-bit 
pointer on the MULTIBUS data lines. The vector 
pointer is used by the bus master to determine the 
memory address of the interrupt service reutine. 


If the bus master generates two additional 
INTA/s, these two INTA/ commands allow the 
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bus slave to put atwo byte interrupt vector address ~ 


on to the MULTIBUS data lines (one byte for each 
INTA/). The interrupt vector address is used by 
the bus master to service the interrupt. 


The MULTIBUS specification provides for only 
one type of Bus Vectored Interrupt operation in a 
given system. Slave boards which have an 8259 
interrupt controller are only capable of 3 INTA/ 
operation (2 additional INTA/s after the first 
INTA/). Slave boards with the 8259A interrupt 
controller are capable of either 2 INTA/ or 3 
INTA/ operation. All slave boards in a given 
system must operate in the same way (2 INTA/sor 
3 INTA/s) if Bus Vectored Interrupts are to be 
used. However, the MULTIBUS specification 
does provide for Bus Vectored Interrupts and Non 
Bus Vectored Interrupts in the same system. 


MULTIBUS Multi-Master Operation — The 
MULTIBUS system bus can accommodate several 
bus masters on the same system, each one taking 
control of the bus as it needs to affect data trans- 
fers. The bus masters request bus control through 
a bus exchange sequence. 


Two bus exchange priority resolution techniques 
are discussed, a serial technique and a parallel 
technique. Figures 8 and 9 illustrate these two 
techniques. The bus exchange operation dis- 
cussed later is the same for both techniques. 


Serial Priority Technique 

Serial priority resolution is accomplished with a 
daisy chain technique (see Figure-8). The priority 
input (BPRN/) of the highest priority master is 


tied to ground. The priority output (BPRO/) of the ~ 


HIGHEST 
PRIORITY 
MASTER 


highest priority master is then connected to the 
priority input (BPRN/) of the next lower priority 
master, and so on. Any master generating a bus 
request will set its BPRO/ signal high to the next 
lower priority master. Any master seeing a high 
signal on its BPRN/ line will sets its BPRO/ line 
high, thus passing down priority information to 
lower priority masters. In this implementation, 
the bus request line (BREQ/) is not used outside of 
the individual masters. A limited number of 
masters can be accommodated by this technique, 
due to gate delays through the daisy chain. Using 
the current Intel MULTIBUS controller chip on 
the master boards up to 3 masters may be accom- 
modated if a BCLK/ period of 100 ns is used. If 
more bus masters are required, either BCLK/ must 
be slowed or a parallel priority technique used. 


Parallel Priority Technique _ 


In the parallel priority technique, the priority is 
resolved in a priority resolution circuit in which 
the highest priority BREQ/ input is encoded with 
a priority encoder chip (74148). This coded value is 
then decoded with a priority decoder chip (748138) 
to activate the appropriate BPRN/ line. The 
BPRO/ lines are not used in the parallel priority 
scheme. However, since the MULTIBUS back- 
plane contains a trace from the BPRN/ signal of 
one card slot to the BPRO/ signal of the adjacent 
lower card slot, the BPRO/ must be disconnected 
from the bus on the board or the backplane trace 
must be cut. A practical limit of sixteen masters 


can be accommodated using the parallel priority 


technique due to physical bus length limitations. 
Figure 9 contains the schematic for a typical 
parallel resolution network. Note that the parallel 


- priority resolution network must be externally 


supplied. 


LOWEST 
PRIORITY 
MASTER 


Figure 8. Serial Priority Technique 
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Figure 9. Parallel Priority Technique 


MULTIBUS Exchange Operation — A timing 
diagram for the MULTIBUS exchange operation 
is shown in Figure 10. This implementation 
example uses a parallel resolution scheme, how- 
ever, the timing would be basically the same for 
the serial resolution scheme. 


In this example, master A has been assigned a 
lower priority than master B. The bus exchange 
occurs because master B generates a bus request 
during a time when master A has control of the 
bus. 


The exchange process begins when master B 
requires the bus to access some resource such as an 
I/O or memory module while master A controls the 
bus. This internal request is synchronized with 
the trailing edge (high to low) of BCLK/ to 
generate a bus request (BREQ/). The bus priority 
resolution circuit changes the BPRN/ signal from 
active (low) to inactive (high) for master A and 
from inactive to active for master B. Master A 
must first complete the current bus command if 
one is in operation. After master A completes the 
command, it sets BUSY/ inactive on the next 
trailing edge of BCLK/. This allows the actual bus 
exchange to occur, because master A has relin- 
quished control-of the bus, and master B has been 
granted its BPRN/. During this time, the drivers 
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for master A are disabled. Master B must take 
control of the bus with the next trailing edge of 
BCLK/ to complete the bus exchange. Master B 
takes control by activating BUSY/ and enabling 
its drivers. 


It is possible for master A to retain control of the 
bus and prevent master B from getting control. 
Master A activates the Bus Override (or Bus Lock) 
signal which keeps BUSY/ active allowing con- 
trol of the bus to stay with master A. This 
guarantees a master consecutive bus cycles for 
software or hardware functions which require 
exclusive, continuous access to the bus. 


Note that in systems with only a single master it is 
necessary to ground the BPRN/ pin of the master, 
if slave boards are to be accessed. In single board 
systems which use a CPU board capable of Bus 
Vectored Interrupt operation, the BPRN/ pin must 
also be grounded. 


In a single master system bus transfer efficiency 
may be gained if the BUS OVERRIDE signal is 
kept active continuously. This permits the master 
to maintain control of the bus at all times, there- 
fore saving the overhead of the master reacquiring 
the bus each time it is needed. 


The CBRQ/ line may be used by a master in 
control of the bus to determine if another master 
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Figure 10. Bus Control Exchange Operation 


requires the bus. If amaster currently in control of 
the bus sees the CBRQ/ line inactive, it will 
maintain control of the bus between adjacent bus 
accesses. Therefore, when a bus access is required, 
the master saves the overhead of reacquiring the 
bus. If a current bus master sees the CBRQ/ line 
active, it will then relinquish control of the bus 
after the current bus access and will contend for 
the bus with the other master(s) requiring the bus. 
The relative priorities of the masters will deter- 
mine which master receives the bus. 
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power failures. 


Note that except for the BUS OVERRIDE state, no 
single master may keep exclusive control of the 
bus. This is true because it is impossible for the 
CPU on a master to require ccntinuous access to 
the bus. Other lower priority masters will always 


be able to gain access to the bus between accesses 


of a higher priority master. 


Power Fail Considerations —TheMULTIBUS 
P2 connector signals provide a means of handling 
The circuits required for power 
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Figure 11. Power Fail Timing Sequence 


failure detection and handling are optional and 
must be supplied by the user. Figure 11 shows 
the timing of a power fail sequence. 


The power supply monitors the AC power level. 
When power drops below an acceptable value, the 
power supply raises ACLO which tells the power 
fail logic that a minimum of three milliseconds will 
elapse before DC power will fall below regulated 
voltage levels. The power fail logic sets a sense 
latch (PFSN/) and generates an interrupt (PFIN/) 
to the processor so the processor can store its 
environment. After a 2.5 millisecond timeout, the 
memory protect signal (MPRO/) is asserted by the 
power fail logic preventing any memory activity. 
As power falls, the memory goes on standby 
power. Note that the power fail logic must be 
powered from the standby source. | 


As the AC line revives, the logic voltage level is 
monitored by the power supply. After power has 
been at its operating level for one millisecond 
minimum, the power supply sets the signal ACLO 
low, beginning the restart sequence. First, the 
memory protect line (MPRO/) then the initialize 
line (INIT/) become inactive. The bus master now 
starts running. The bus master checks the power 
fail latch (PFSN/) and, if it finds it set, branches to 
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a power up routine which resets the latch (PFSR/), 
restores the environment, and resumes execution. 


Note that INIT/ is activated only after DC power 
has risen to the regulated voltage levels and must 
stay low for five milliseconds minimum before the 
system is allowed to restart. Alternatively, INIT/ 
may be held low through an open collector device 
by MPRO/. 


How the power failure equipment is configured is 
left to the system designer. The backup power 
source may be batteries located on the memory 
boards or more elaborate facilities located off- 
board. The location of the power: fail logic 
determines which MULTIBUS power fail lines are 
used. Pins on the P2 connector have been specified 
for the power failure functions for use as needed. 


To further clarify the location and use of the power 
fail circuitry, an example of a typical power fail 
system block diagram is shown in Figure 12. A 
single board computer and a slave memory board 
are contained in the system. It is desired to power 
the memory circuit elements of the memory board 
from auxiliary power. The single board computer 
will remain on the main power supply. To ac- 
complish this, user supplied power fail logic and 
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Figure 12. Typical Power Fail System Block Diagram 


an auxiliary power supply have been included in 
the system. 


The single board computer is powered from the P1 
power lines and accesses the P2 signal lines 
PFIN/, PFSN/ and PFSR/ (only the P2 signal 
lines used by a particular functional block are 
shown on the block diagram). The PFSR/ line is 
driven from two sources: a front panel switch and 
the single board computer. The front panel switch 
is used during normal power-up to reset the power 
fail sense latch. The single board computer uses 
the PFSR/ line to reset the latch during a power-up 
sequence after a power failure. Current single 
board computers must access the PFSN/ and 
PFSR/ signals either directly with dedicated 
circuitry and a P2 pin connection or through the 
parallel I/O lines with a cable connection from the 
parallel I/O connector to the P2 connector. 


The slave memory board uses both the P1 and P2 
power lines, the P2 power lines are used (at all 
times) to power the memory circuit elements and 
other support circuits, the P1 power lines power all 
other circuitry. In addition, the MPRO/ line is 
input and used to sense when memory contents 
should be protected. 


The power fail logic contains the power fail sense 
latch, and uses the PFSR/ and ACLO lines for 
inputs and the PFIN/ PFSN/, and MPRO/ lines 
for outputs.. The power fail logic must be powered 
by the P2 power lines. 
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DC Requirements — The drive and load charac- 
teristics of the bus signals are listed in Appendix 
C. The physical locations of the drivers and loads, 


~ as well as the terminating resistor value for each 


bus line, are also: specified. Appendix D contains 


_the MULTIBUS power specifications. 


MULTIBUS™ Slave Interface 
Circuit Elements 


There are three basic elements of a slave bus 
interface: address decoders, bus drivers, and 
control signal logic. This section discusses each of 
these elements in general terms. A description of a 
detailed implementation of a slave interface is 
presented in a later section of this application note. 


Address Decoding — This logic decodes the 
appropriate MULTIBUS address bits into RAM 
requests, ROM requests, or I/O selects. Care must 


_ be taken in the design of the address decode logic 


to ensure flexibility in the selection of base address 
assignments. Without this flexibility, restrictions 
may be placed upon various system configura- 
tions. Ideally, switches and jumper connections 
should be associated with the decode logic to 
permit field modification of base address assign- 
ments. 


The initial step in designing the address decode 
portion of a MULTIBUS interface is to determine 
the required number of unique address locations. 
This decision is influenced by the fact that 
address decoding is usually done in two stages. 
The first stage decodes the base address, pro- 
ducing an enable for the second stage which 
generates the actual device selects for the user 
logic. A convenient implementation of this two 
stage decoding scheme utilizes a pair of decoders 
driven by the high order bits of the address for the 
first stage and a second decoder for the low order 
bits of the address bus. This technique forces the 
number of unique address locations to be a power 
of two, based at the address decoded by the first 
stage. Consider the scheme illustrated in Figure 
13. 


As shown in Figure 13, the address bits A4- AB are 
used to produce switch selected outputs of the first 
stage of decoding. The 1 out of 8 binary decoders 
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have been used. The top decoder decodes address 
lines Aq - A7, and the bottom decoder decodes 
address lines Ag- Ap. If only address lines Ag-A7 
are being used for device selection, as in the case of 
I/O port selection in 8-bit systems, the bottom 
decoder may be disabled by setting switch S2 to the 
ground position. Address lines A7 and Ap drive 
enable inputs E2 or E3 of the decoders. The 
address lines Ag - A3 enter the second stage 
address decoder to produce 8 user device selects. 
The second stage decoder must first be enabled by 
an address that corresponds to the switch-selected 
base address. 


Address decoding must be completed before the 
arrival of a command. Since the command may 
become active within 50 ns after stable address, 
the decode logic should be kept simple with a 
minimal number of layers of logic. Furthermore, 
the timing is extremely critical in systems which 
make use of the inhibit lines. 


A linear or unary select scheme in which no binary 
encoding of device address (e.g., address bit Ag 
selects device 0, address bit A 1 selects device 1, 
etc.) is performed is not reeommended because the 
scheme offers no protection in case multiple 
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Figure 13. Two Stage Decoding Scheme 
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devices are simultaneously selected, and because 
the addressing within such a system is restricted 
by the extent of the address space occupied by such 
a scheme. 


Data Bus Drivers — For user designed logic 
which simply receives data from the MULTIBUS 
data lines, this portion of the bus interface logic 
may only consist of buffers. Buffers are required 
to ensure that maximum allowable bus loading is 
not exceeded by the user logic. _ 


In systems where the user designed logic must 
place data onto the MULTIBUS data lines, three- 
state drivers are required. These drivers should be 
enabled only when a memory read command 
(MRDC/) or an I/O read command (IORC/) is 
present and the module has been addressed. 


When both the read and write functions are re- 
quired, parallel bidirectional bus drivers (e.g., Intel 
8226, 8287, etc.) are used. A note of caution must be 
included for the designer who uses this type of 
device. A problem may arise if data hold time 
requirements must be satisfied for user logic 
following write operations. When bus commands 
are used to directly produce both the chip select for 
the bidirectional bus driver and a strobe to a latch 
in the user logic, removal of. that signal may not 
provide the user’s latch with adequate data hold 
time. Depending on the specifics of the user logic, 
this problem may be solved by permanently 
enabling the data buffer’s receiver circuits and 
controlling only the direction of the buffers. 


Control Signal Logic — The control signal logic 
consists of the circuits that forward the I/O and 
memory read/write commands to their respective 
destinations, provide the bus with a transfer 
acknowledge response, and ae the ‘System 
interrupt lines. 


Bus Command Lines 


The MULTIBUS information transfer protocol 
lines (MRDC/, MWTC/, IORD/. and IOWC/) 
should be buffered by devices with very high speed 
switching. Because the bus DC requirements 
specify that each board may load these lines with 
2.0 mA, Schottky devices are recommended. LS 
devices are not recommended due to their poor 
noise immunity. The commands should be gated 
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with a signal indicating the base address has been 
decoded to generate read and write strobes for the 
user logic. 7 


Transfer Acknowledge Generation 


The user interface transfer acknowledge genera- 
tion logic provides a transfer acknowledge re- 
sponse, XACK/, to notify the bus master that write 
data provided by the bus master has been accepted 
or that read data it has requested is available on 
the MULTIBUS data lines. XACK/ allows the bus 
master to conclude its current instruction. 


Since XACK/ timing requirements depend on both 
the CPU of the bus master and characteristics of 
the user logic, a circuit is needed which will provide 
a range of easily modified acknowledge responses. 


The transfer acknowledge signals must be driven 
by three-state drivers which are enabled when the 
bus interface is addressed and a command is 
present. 


Interrupt Signal Lines» 


The asynchronous interrupt lines must be driven 
by open collector devices with a minimum drive of 
16 mA. 


In a typical Non Bus Vectored Interrupt system, 
logic must be provided to assert and latch-up an 
interrupt signal. In addition to driving the 
MULTIBUS interrupt lines, the latched interrupt 
signal would be read by an I/O operation such as 
reading the module’s status. The interrupt signal 
would be cleared by writing to the status register. 


Iil. -MULTIBUS™ Snes DESIGN 
~ EXAMPLE © 


A: MULTIBUS slave dlesiwa example has been 
included in this application note to reinforce the 
theory previously discussed. The design example 
is of general purpose I/O slave interface. This 
design example could easily be modified to be used 
as a slave memory interface by buffering the 
address signals and using the appropriate 
MULTIBUS memory commands. In addition, to 
help the reader better understand an application 
for an I/O slave interface, two Intel 8255A Parallel 
Peripheral Interface (PPT) devices are shown con- 
nected to the slave interface. | 


The design sample is shown in both 8/16-bit 
version and an &-bit version. The 8/16-bit version 
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is an I/O interface which will permit a 16-bit 
master to perform 8 or 16 bit data transfers. 8-bit 
masters may also use the 8/16-bit version of the 
design example to perform 8-bit data transfers. 


The 8-bit version of the design example may be 
used by both 8 or 16-bit masters, but will only 
perform 8-bit data transfers. It does not contain 
the circuitry required to pertoray 16- bit data 
transfers. 


Both the 8/16-bit version and the 8-bit geicion of 
the design example were implemented on an iSBC 
905 prototype board. The schematics for each of 
the examples are given in Appendices F and G. 


Functional/Programming Characteristics 


This section describes the organization of the 
slave interface from two points of view, the 
functional point of view and the programming 
characteristics. First, the principal functions 
performed by the hardware are identified and the 
general data flow is illustrated. This point of view 
is intended as an introduction to the detailed 
description provided in the next'section; Theory of 
Operation. In the second point of view, the 
information needed by a programmer to access the 
slave is summarized. 


Functional Description — The function of this 
I/O slave is to provide the bus interface logic for 
general purpose I/O functions and for two Intel 
8255A Parallel Peripheral Interface (PPI) devices. 
Hight device selects (port addresses) are available 
for general purpose I/O functions. One of these 
device select lines is used to read and reset the state 
of an interrupt status flip-flop, the other seven 
device selects are unused in this design. An 
additional eight I/O device port addresses are 
used by the two 8255A devices; four I/O port 
addresses per 8255A (three I/O port address for 
the three parallel ports A, B, and C and the fourth 
I/O port address for the device control register). 


Figure 14 contains a functional block diagram of 
the slave design example. This block diagram 
shows the fundamental circuit elements of a bus 
slave: bidirectional data bus drivers/receivers, 
address decoding logic and bus control logic. Also 
shown is the address decoding logic for the low 
order four bits, the interrupt logic which is selected 
by this decoding logic, and the two 8255A devices. 
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Figure 14. MULTIBUS™ Slave Design Example 
Functional Block Diagram 


Programming Characteristics — The slave 
design example provides 16 I/O port addresses 
which may be accessed by user software. The 
base address of the 16 contiguous port addresses 
is selected by wire wrap connections on the proto- 
type board. The wire wrap connections specify 
address bits ADR4/ - ADRB/. They allow the 
selection of a base address on any 16 byte 
boundary. Twelve address bits (ADRO/ - ADRB/) 
are used since 16-bit (8086 based) masters use 12 
bits to specity I/O port addresses. If an 8 bit (8080 
or 8085 based) master is used with this slave board, 
the high order address bits (ADR8/- ADRB/) must 
not be used by the decoding circuits; a wire wrap 
jumper position (ground position) is provided for 
this. 7 7 


The 16 I/O port addresses are divided into two 
groups of 8 port addresses by decoding address line 
ADR3/. Port addresses XXO - XX7 are used for 
general I/O functions (XX indicates any hexi- 
decimal digit combination). Port address XXO0 is 
used for accessing the interrupt status flip-flop and 
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port addresses XX1 - XX7 are not used in this 
example. Port addresses XX8 - XXF are used for 
accessing the PPIs. If port addresses XX8 - XXF 
are selected, then ADRO/ is used to specify which 
of two PPIs are selected. If the address is even 
(XX8, XXA, XXC, or XXE) then one PPI is selected. 
If the address is odd (XX9, XXB, XXD, or XXF), 
then the other PPI is selected. ADR1/ and ADR2/ 
are connected directly to the PPIs. Table 1 
summarizes the I/O port addresses of the slave 
design example. Note that if a 16-bit master is 
used, it is possible to access the slave in a byte or 
word mode. If word access is used with port 
address XX8, XXA, XXC, or XXE, then 16 bit 
transfers will occur between the PPIs and the 
master. These 16 bit transfers occur because an 
even address has been specified and the MULTI- 
BUS BHEN/ signal indicates that a 16-bit 
transfer is requested. 


Theory of Operation 


In the preceding section, each of the slave design 
example functional blocks was identified and - 
briefly explained. This section explains how these 
functions are implemented. For detailed circuit 
information, refer to the schematics in Appendices 
F and G. The schematic in Appendix F is on a 
foldout page so that the following text may easily 
be related to the schematic. 


The discussion of the theory of operation is divided 
into five segments, each of which discusses a 
different function performed by the MULTIBUS 
slave design example. The five segments are: 


1. Bus address decoding 

2. Data buffers 

3. Control signals 

4. Interrupt logic 

5. PPI operation | 
Each of these topics are discussed with regard to 
the 8/16-bit version of the design example; 
followed by a discussion of the circuit elements 
which are required by the 8-bit version of the 
interface. . - 


Bus Address Decoding — Bus address decoding 
is performed by two 8205 | out of 8 binary decoders. 
One decoder (A8) decodes address bits ADR8/ - 
ADRB/ and the second decoder (A2) decodes 
address bits ADR4/ - ADR7/. The base address 
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Unused 
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Table 1 


SLAVE DESIGN EXAMPLE PORT ADDRESSES 


Parallel Port A, Even and Odd PPls 
Parallel Port B, Even and Odd PPIs 
Parallel Port C, Even and Odd PPIs __ 


[cevteaccess, | OSOCOCOC—OSOCO [| 


Reset Interrupt Status 
Unused | 

Parallel Port A, Even PPI 
Parallel Port A, Odd PPI 
Parallel Port B, Even PPI 
Parallel Port B, Odd PPI 
Parallel Port C, Even PPI 
Parallel Port C, Odd PPI 
Control, Even PPI 
Control, Odd PPI 


Reset Interrupt Status 

Unused | ; 
iParallel Port A, Even and Odd PPIs 
Parallel Port B, Even and Odd PPIs — 
Parallel Port C, Even and Odd PPIs 
Control, Even and Odd PPIs 


XX = Any hex digits, assigned by jumpers; XX defines the base address. 


selected is determined by the position of wire wrap 
jumpers. The outputs of the two decoders are 
ANDed together to form the BASE ADR SELECT/ 
signal. ‘ This signal specifies the base address 
for a group of 16 I/O ports. Using the wire wrap 
jumper positions shown in the schematic, a base 
address of E3 has been selected. Therefore, this 


MULTIBUS slave board will respond to I/O port. 


addresses in the E380 - E3F range. 


If this slave board is to be used with 8-bit MULTI- 
BUS masters, the high order address bits must not 
be decoded. Therefore, the wire wrap jumper 
which selects the output of decoder A3 must. be 
placed in the top (ground) position (pin 10 of gate 
AQ to ground). ih ne 2 nr 


The low order 4 address lines (ADRO/- ADR3/) are 
buffered and inverted using 74LS04 inverters. 
These address lines are input to an 8205 for 
decoding a chip select for the interrupt logic; the 
address lines are also used directly by the PPIs. 
LS-Series logic is required for buffering to meet the 
MULTIBUS specification for Ij], (low level input 
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current). S-Series or standard series logic will not 
meet this specification. 


Address decoder A4 is used to decode addresses 
E30 - E37. The CSO0/ output of this decoder is used 
to select the interrupt logic, thus I/O port address 
E30 is used to read and reset the interrupt latch. 
The remaining outputs from decoder A4 (CS1/ - 
CS7/) are not used in this example. They would 
normally be used to select other functions in a 
slave board with more capability. Note that in the 
schematic shown in Appendix G for the 8-bit 
version of this slave design example, the high 
order (ADR8/ - ADRB/) address decoder is not 
included and the BHEN/ signal is not used. 


Data: Buffers — Intel 8287 8-bit parallel bi- 
directional bus drivers are used for the MULTI- 
BUS data lines DATO/ - DATF/. In the 8/16-bit. 
version of the slave board, three 8287 drivers 
are used. _ 


When an 8-bit data transfer is requested, either 
driver A5, which is connected to on-board data 
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lines DO - D7, or driver A6, which is connected to 
on-board data lines D8 - DF, is used. If a byte 
transfer is requested from an even address, driver 
A5 will be selected. If a byte transfer from an odd 
address is requested, driver A6 will be selected. All 
byte transfers take place on MULTIBUS data 
lines DATO/ - DAT7/. When a word (16-bit) 
transfer is requested from an even address, drivers 
Ad and A7 will be used. Note that ifa user program 
requests a word transfer from an odd address, 
16-bit masters in the iSBC product line will 
actually perform two byte transfer requests. 


The logic which determines the chip selection 
(8287 input signal OE, output enable) signals for 
the bus drivers uses the low order address bit 
(ADRO/) and the buffered Byte High Enable 
signal (BHENBL/). Note that the MULTIBUS 
signal BHEN/ has been buffered with an 74LS04 
inverter. This is done to meet the bus address line 
loading specification. The SWAP BYTE/ signal 
which is generated is qualified by the BD ENBL/ 
signal and used to select the bus drivers. 


The steering pin for the 8287 drivers is labelled T 
(transmit) and is driven by the signal RD. When 
an input (read) request is active or when neither a 
read or write command is being serviced, the 
direction of data transfer of the 8287 will be set for 
B to A. 


The 8287 drivers are set to point IN (direction B to 
A) when no MULTIBUS I/O transfer command is 
being serviced for two reasons. First, if the driver 
were pointed OUT (direction A to B) and a write 
command occured, it would be necessary to turn 
the buffers IN and set the OE (output enable) 
signal active before the data could be transferred 
to the on-board bus. A possibility of a “buffer- 
fight” could occur in some designs if the OE signal 
permitted an 8287 to drive the MULTIBUS data 
lines momentarily before the steering signal could 
switch the direction of the 8287. In this case, both 
the MULTIBUS master and the slave would be 
driving the data lines; this is not recommended. 
(In this particular design, the steering signal will 
always stabilize before the OE signal becomes 
active.) 


The pena reason the driver is sone IN when 
no command is present is due to the “data valid 
after WRITE” requirements of the 8255As. The 
8255A requires that data remain on its data lines 
for 30 ns after the WRITE command (WR at the 
8255A) is removed. This requirement will be met if 
the direction of the 8287 drivers is not switched 
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when the MULTIBUS IOWC,/ signal is removed 
(WRT/ could have been used to steer the 8287 
instead of RD); and if the capacitance of the on- 
board data bus lines is sufficient to hold the data 
values on the bus after the 8287 OE signal and the 
8255A PPI WRT/ signal goinactive. The on-board 
data bus may easily be designed such that the 
capacitance of the lines is sufficient to meet the 30 
ns data hold time requirement. In addition, the 
current leakage of all devices connected to the on- 
board bus must be kept small to meet the 30 ns data 
hold time requirement. 


The 8-bit version of this design example uses only 
one 8287 instead of the three required by the 8/16- 
bit version. The logic required to control the swap 
byte buffer is also not necessary. The chip select 
signal used for the 8287 is the BD ENBL/ signal. 


Control Signals — The MULTIBUS control 
signals used by this slave design example are 
IORC/, IOWC/, and XACK/. IORC/ and IOWC/ 
are qualified by the BASE ADR SELECTY signal 
to form the signals RD and WRT. RD and WRT 
are used to drive the interrupt logic, the PPI logic 
and the XACK/ (transfer acknowledge) logic. 


For the XACK/ logic RD and WRT are ORed to 
form the BD ENBL/ signal which is inverted and 
used to drive the CLEAR pin of a shift register. 
When the slave board is not being accessed, the 
CLEAR pin of the shift register will be low (BD 
ENBL/ is high). This causes the shift register to 
remain cleared and all outputs of the shift register 
will be low. When the slave board is accessed, the 
CLEAR pin will be high, and the A and B inputs 
(which are high) will be clocked to the output pins 
by CCLK/. Toselecta delay for the XACK/ signal, 
a jumper must be installed from one of the shift 
register output pins to the 8089 tri-state driver. 
Each of the shift register output pins select an 
integer multiple of CCLK/ periods for the signal 
delay. Since the CCLK/ signal is asynchronous, 
the actual delay selected may only be specified 
with a tolerance of one CCLK/ period. In this 
example a delay of 3 - 4 CCLK/ periods was 
selected; with a CCLK/ pericd of 100 ns, the 
XACK/ delay would occur somewhere within the 
range of 300 - 400 ns from the time when the 
CLEAR signal goes high. 


The control eal logic re in the 8- bit version of 
the slave design example is identical to. the logic 
used in the 8/16-bit version. : 
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Interrupt Logic — The interrupt logic uses a 
74874 flip-flop to latch an asynchronous interrupt 
request from some external logic. The Q output 
of the INTERRUPT REQUEST LATCH i is output 
through an open | collector gate to one of the 
MULTIBUS interrupt lines. The state of the 
INTERRUPT REQUEST LATCH is transferred 
to the INTERRUPT STATUS, LATCH when a 
read command is performed on I/O port BASE 
ADDRESS+0 (E30 for the jumper configuration 
shown). The. Q. output of INTERRUPT STATUS 
LATCH is used to drive data. line DO of the on- 
board data bus by using an 8089 tri-state driver. 
If a user program performs an INPUT from I/O 
port E30, data bit 0 will be set to eG if the IN TER- 
RUPT REQUEST LATCH i is set. 


The purpose of INTERRUPT STATUS LATCH i is 
to minimize the possibility of the asynchronous 
interrupt occuring while the interrupt status is 
being read by a bus master. If the latch was not 
included i in the design and an asynchronous inter- 
rupt_ did occur while a bus master is reading 
MULTIBUS data line DATO/, a data buffer on the 
master could go into a meta- stable state. By 
adding the extra latch, which is clocked by the 
IORD/ command for I/O port E30, the possibility 
of data line DATO/ changing es a bus master 
read operation is eliminated. a 


The INTERRUPT RE QUE ST LATCH j is Cie 
when a user program pee an OUTPUT toI/O 
port E30. 


This" haat structure assumes fiat several 
interrupt sources may exist on the same MULTI- 
BUS interrupt line (for example, INT3/). When the 
MULTIBUS master gets interrupted, it must poll 
the possible sources of the interrupt received and 
after. determining the source of the interrupt, it 
must clear the INTERRUPT REQUEST LATCH 
for that particular interrupt source. ' 


The inteeaipt oni. for the 8- ik version of the 
design example is identical to the interrupt logic of 
the 8/16-bit version of the design example. | 


PPI Operation — Two 8255A Parallel Peripheral. 
Interface (PPI) devices are shown interfaced to 
the slave design example logic.. One PPI is con- 


nected to the on-board data bus lines DO - D7 and 


is addressed with the even I/O port addresses 
E38, E38A, E3C; and’ E8E. The second PPI.is 
connected.to data bus lines.D8 - DF and ‘is'address- 


ed with the odd I/O ‘port addresses E39, E3B,: 
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E3D, and E3F. The even or odd I/O port selection 
is controlled by using. the ADRO address line in 
the chip select term of the PPIs, In addition, the 
odd. PPI (All) is selected when the BHENBL 
term is high. This occurs when the MULTIBUS 
signal BHEN/ is low. indicating that a word 
(16- bit) Ll/O instruction is being executed. When 
a word I/ O instruction is executed, both PPIs will 
perform the 1/ O operation specified. 


The specifications of the 8255A device state that 
the address lines AO and Al and the e chip select 
lines must be stable before the RD or WR lines are 
activated.. The MULTIBUS specification address 
set-up time of 50 ns.and the short gate propagation 
delays in this design assure that the address lines 
are stable before RD or WR are active. 


The data hold requirements of the 8255A" were 
discussed i in a previous section, The 8255A. speci- 
fication states that data will be stable on the data 
bus lines. a maximum of 250 ns ‘after a READ 


command. This specification was used to select 
the delay for the XACK/ signal. — 


The PPI: operation for the 8-bit version of the 
design example is slightly different than that used 
for the 8/16-bit version. The chip select signal for 
the bottom PPI does not use the BHENBL term 
since 16-bit data transfers are not possible with an 
8-bit I/O slave board. Also, the chip select and 
address signals have been swapped so the top PPI 
occupies I/O address range X8 - XB, and the 
bottom PPI occupiés I/O address range XC - XF(X 
is the base address of the 8-bit version). This 
swapping of the address lines was not necessary; 
however, it was thought to be more convenient to 
access the PPIs in two groups of 4 peonueuous L/ O 
Bort addresses. -_ . 


Iv. SUMMARY 


This appliéation ote has shown the structure of 
the. Intel MULTIBUS system bus. The structure 
supports a wide range of system modules from the 


Intel OEM Microcomputer Systems product line 


that can be éxtended with the addition of user 
designed modules. Because the user designed 
modules are no doubt unique to particular applica- 
tions, a goal of this application note has been to 
describe in detail the singular common element - 

the ‘bus interface.: Material has also been 
presented to assist:the systems designer to under- 
standing the bus functions. so ‘that successful 
systems integration can be achieved. * 1s 
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APPENDIX A 
PIN ASSIGNMENT OF BUS SIGNALS ON MULTIBUS BOARD P1 CONNECTOR 


(COMPONENT SIDE) ba (CIRCUIT SIDE) 


MNEMONIC DESCRIPTION DESCRIPTION 


ayes 
t 


POWER 
SUPPLIES 


BUS 
CONTROLS 


BUS 
CONTROLS 
AND 
ADDRESS 


INTERRUPTS 


ADDRESS 
DATA 


POWER 
SUPPLIES 


Signal GND 
+5Vdc 

+ 5Vdc 
+12Vdc 
-5Vdc 
Signal GND 


Bus Clock 

Bus Pri. In 

Bus Busy 

Mem Read Cmd 

1/0 Read Cmd 
XFER Acknowledge 


Reserved 

Byte High Enable 
Common Bus Request 
Constant Clk 

Intr Acknowledge 


Parallel 
Interrupt 
Requests 


Address 
Bus 


Signal GND 
Reserved 
-12Vdc 
+5Vdc 
+5Vdc 
Signal GND 
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Signal GND 
+5Vdc 

+ 5Vdc 
+12Vdc 
-5Vdc 
Signal GND 


Initialize 

Bus Pri. Out 

Bus Request 

Mem Write Cmd 

1/O Write Cmd 
Inhibit 1 disable RAM 


Inhibit 2 disable PROM or ROM 
Address 
Bus 


Parallel 
Interrupt 
Requests 


Address 
Bus 
Data 
Bus 


Signal GND 
Reserved 
-—12Vdc 

+ 5Vdc 

+ 5Vdc 
Signal GND 
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_ APPENDIX A (Continued) 
P2 CONNECTOR PIN ASSIGNMENT OF OPTIONAL BUS SIGNALS... 
__ (COMPONENT SIDE) 
. MNEMONIC | DESCRIPTION. 


..... (CIRCUIT SIDE) 


~ GND 
5 VB 


-5 VB 


12 VB 
_PFSR/ 
-12 VB 
PFSN/ 
PFIN/ 
GND 
+15V 
-15V 
PAR1/ 
PAR2/ 


Reserved 


Notes: 


“Signal GND 


+5V Battery 
Reserved | 


-5V Battery | 


Reserved 

+12V Battery | 

Power Fail Sense Reset 
-12V Battery | 


_ Power Fail Sense 
~ Power Fail Interrupt 


Signal GND 
+15V 
—-15V 


~ Parity 1 


Parity 2 


2. All undefined pins are reserved for future use. 
All Mnemonics © Intel Corporation 1978 
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MNEMONIC | 


—-=5.VB 


Reserved 
12VB 
Reserved | 
-12 VB - 
ACLO 
MPRO/ 
GND 

+ 15V 
—15V 
HALT/ 
WAIT/ 
ALE 
Reserved 


~ Reserved 


AUX RESET/ 


Reserved 


1. PFIN, on slave modules, if possible, should have the option of connecting to INTO/ on P1. 


_. . DESCRIPTION 


Signal GND - 


+5V Battery 


—+5V Pulsed Power 


—SV Battery . 
+12V Battery 
~12V Battery 


AC Low © 
Memory Protect 


Signal GND | 


+.15V 

—15V ae 

Bus Master HALT 

Bus Master WAIT STATE 
Bus Master ALE 


Reset switch 
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APPENDIX B 
BUS TIMING SPECIFICATIONS SUMMARY 


Parameter Description 


tBCY Bus Clock Period 100 DC. 


tBw Bus Clock Width 0.35 tBcy 0.65 tacy 
(Not Restricted) 


'SKEW BCLK/skew 3 


tPD Standard Bus 3 
Propagation Delay 


tas Address Set-Up Time 
(at Slave Board) 


tos Write Data Set 
Up Time 


tAH Address Hold Time 


tDHW Write Data Hold Time 


tDXL Read Data Set 
Up Time To XACK 


tDHR Read Data Hold Time 


tXAH Acknowledge Hold 
Time 


tXACK Acknowledge Time 


tCMD | Command Pulse 9.5 
Width . 


tiD Inhibit Delay 100 
(Recommend < 100 ns) | 


tXACKA Acknowledge Time of tap + 50 ns 1500 
of an Inhibited Slave 
tXACKB Acknowledge Time of 1.5 8 
; an Inhibiting Slave 

tlAD Acknowledge Disable 0 100 
from Inhibit (An (arbitrary) 
internal parameter on 
an inhibited slave; 
used to determine 


tXACKA Min.) 


Address to Inhibits 
High Delay 


INTA/ Width 
Command Separation 
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Parameter 


(BREQL 
'BREQH 
tBPRNS 
‘BUSY 

tBUSYS 
tBPRO 

tBPRNO 


'CBRO 


tCBRQS 
txCD 
tBSsYO 


tCCY 
tcw 
tINIT 


tINITS 
tPBD 


tPFINW 
tMPRO 
tACLOW 
tPFSRW 
{TOUT 
~ tDCH 


tocs 


Description 


4BCLK/ to BREQ/ 
Low Delay 


4‘BCLK/ to BREQ/ 
High Delay 
BPRN/ to }BCLK/ 
Setup Time 


BUSY/ delay 
from }BCLK/ 


BUSY/ to ‘;BCLK/ 
Setup Time 


4BCLK/ to BPRO/ 
(CLK to Priority Out) 


BPRN/ to BPRO/ 
(Priority In to Out) 


+BCLK/ to CBRQ/ 
(CLKto Common 
Bus Request) 


CBRQ/ to !BCLK/ 
Setup Time 


XACK! to Command! 
Delay 


CBRQ/! and BUSY/| 
to BUSY/! 


C-clock Period 
C-clock Width 
INIT/Width 


INIT/ to MPRO/ 
Setup Time 


Power Backup 
Logic Delay 


PFIN/ Width 


MPRO/ Delay 
ACLO/ Width 
PFSR/ Width 
Timeout Delay 


D.C. Power Supply 
Hold from ALCO/ 


D.C. Power Supply 
Setup to ACLO/ 
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APPENDIX B (Continued) 
BUS TIMING SPECIFICATIONS SUMMARY 


0.35 tccy 
5 


100 


0 
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Maximum | 
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APPENDIX C 
BUS DRIVERS, RECEIVERS, AND TERMINATIONS 


_ Bus Signals Location Type lol lon Co. Location Ne NH C; |Location| Type 
Minma Minua Maxpf Maxma Maxia Maxpf 


DATO/+DATF/ | Masters -2000 300 | Masters Pullup 
(16 lines) and Slaves and Slaves 


AOR0/-ADORB/, | Masters -2000 300 | Slaves Pullup 


BHEN/ 
(21 lines) 


MRDC/,MWTC/ } Masters Slaves 
(Memory; 
memory- 
mapped |/O) 


IORC/,IOWC/ Masters Slaves ; Pullup 
(1/0) 


XACK/ Slaves Masters Pullup 


INH1/,INH2/ Inhibiting inhibited Pullup 
Slaves Slaves 
(RAM, PROM, 
ROM, Memory- 
Mapped !/O) 


1pl Master .. Mother- | To +5V | 220 
Ngee) board To GND | 330 


Each Central Central Pullup 
Master Priority Priority 
Module Module 
(not req) 


Each Next Master (not req) 
Master in Serial 

Priority 

Chain at 

its BPRN/ 


Parallel: Master (not req) 
Central 

Priority 

Module 

Serial:Prev 

Masters 

BPRO/ 


BUSY/, CBRQ All Masters C. All Masters 


INIT/ Master. Cc. All 


CCLK/ 1 place Any To +5V | 220 
To GND] 330 


INTA/ Masters Slaves Pullup 
(Interrupting 
1/O) 


INTO/--INT7/ Slaves Loy Masters Pullup 
(8 lines) 


PFSR/ User's Fron Slaves, ; Pullup 
Panel? Masters 


PFSN/ Power Back Masters Pullup 
Up Unit 


ACLO Power C; Slaves, Pullup 
Supply Masters 


PFIN/ Power Back- C. Masters Pullup 
Up Unit 


MPRO/ Power Back- Slaves Pullup 
Up Unit Masters 
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APPENDIX C (Continued) 
BUS DRIVERS, RECEIVERS, AND TERMINATIONS 


Driver 1, 30 | sReceiver2.3 3 ae | 


Bue aa Location Type lot OH Location Ne AH ‘Location Tsai aa 
Minma Minva aa Maxme Max,a ee 


Aux Reset/ 


. Driver Requirements 


High Output Current Drive 
Low Output Current Drive 
Capacitance Drive Capebility 
3-State Drive 

Open Collector Driver 
Totem-pole Driver 

. Receiver Requirements 


Ts) High input Current Load ~ 
Wt Low Input Current Load 
Ci Capacitive Load 


. TTL low state must be > -0.5v but <0.8v at the receivers 
TTL high state must be > 2.0v but < 5.5v at the receivers 


4. For the iSBC 80/10 and the iSBC 80/10A use only a 1K pull-up resistor to +5v for BCLK/ and CCLK/ termination. 
. Recommend a 472 resistor in series with switch. 
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APPENDIX D 
BUS POWER SPECIFICATIONS 


fo Standard (P1) Optional (P2) 
P| Anattog Power Battery Power Backup 


Ground +5 +12 —12 -—5 
Mnemonic + 5V +12V —12V +5B +12B — 5B 
Bus Pins P1+3,4, P1+7,8 P1+/79, P2+3,4, P2+11, P2—7,8 
5,6,81, 80 5,6 
82,83, 
84 


Nominal Output ; +5.0V + 15.0V 


Tolerance from 
Nominal’ . +5% + 3% 


Ripple 
(Pk-Pk)? ; 50 mV 10 mV 


Transient 
Response 500 us 100 us 
Time? 
| Transient 
Deviation‘ +10% 


NOTES: 
. Tolerance is worst case, including initial voltage setting line and load effects of power source, temperature drift, and any additional steady 
State influences. 
. AS measured over any bandwidth not to exceed 0 to 500 kHz. 
. AS measured from the start of a load change to the time an output recovers within + 0.1% of final voltage. 
. Measured as the peak deviation from the initial voltage. 
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| APPENDIX E 
MECHANICAL SPECIFICATIONS 


12.00 


0.25 X 45° Eee —. 11,500 
“2 PLACES . ; : 


+0,005 


8.109 DIA 
3 HOLES 
COMPONENT SIDE 
6.75 REF 
U > : , ° 
0.06R — 5 i ~ _ p A 
TYP | 0.55 4 0.30 
/ Ls oe 3.080 ee ‘ - 0.390 
6.835 + 0.007 | 0.015 + 0.005 x 45° 
-5 ° es g ° CHAMFER ALL 2 PLACES 
ae a = & CONNECTOR EDGES ; 
a) st road ° 0.040 « 45° 
- 4! 
NOTES: 
i1.> BOARD THICKNESS: 0.062 EJECTOR TYPE: SCANBE 28203 
12> MULTIBUS CONNECTOR: 86-PIN, 0.156 SPACING 5. BUS DRIVERS AND RECEIVERS SHOULD BE LOCATED AS CLOSE AS POSSIBLE TO 


THEIR RESPECTIVE MULTIBUS PIN CONNECTIONS 
[>> AUXILIARY CONNECTOR: 60-PIN, 0.100 SPACING 


bad 


BOARD SPACING: 0.6 
7. COMPONENT HEIGHT: 0.4 


8. CLEARANCE ON CONDUCTOR NEAR EDGES: 0.050 
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APPENDIX F 
MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 
8/16-BIT VERSION 
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QL-1 


VLEGLO-NAV 


D 
MULTIBUS CONNECTOR 
PI 
INT 7 
INT 7/ SS ee 
u 12) . ; 
tf it 
[en] ae 741504 
9N.B 5K © 
B 
GEN Al74iS04 | Ali ~7ASGA Rone 
es BHENBL 4 
fs 7b} 87 
ADRG/ a casa ? ag |Po / INT @/ 
] 7| 82052 P 5 —— C5 0/ INT I/ 
ee ci crema cy} 
esd A\ | 4 \\ INT2/__! 
ADR2/ 2 cl | = C5 3/ zs 
Al > = 
came 5 2b--——— 05 2/ 
i 14 
ADR?/ + A EZ | e————. (S |/ 
a | CS @/ 
ce 
INTERRUPT 
OK 92 | REC LATCH 
2 DB 
1A (ON-BOARD DATA BUS) 
BOOB 
Bre uh 
| A T4s04 
o— 
PPI WRT/ 
PPI RD/ 
Mee RD 
)B-1 CALK, BD EN&L/ 
, (2-2 
: (S\ZSCCLK BOK? 
oA ¢ | 3) 45¢e , MNP B 
Alu T4504 SS eee ROR 2 sh DB-D7 
5) GTC | ADR | Ne 
XALK/SAIFT Grae ? | AIO 255K 
REGSTER 4 LO TEER | ADR GD Shi PAG 
2) CUR ——— 
INIT Pore | L/O PORTS (24 LINES) 
PPL RD/ 
PPI WR/ 
ADK 2 D&-DF 
J ADR | 
ADR B 
SBHENEK T/O PORTS (24 LINES) 
BHENBL/ Odd PEL 
ADR @ 
BD ENBL/ 
: 5 woe sowens WE 
ae A uaa intel zara cass 
Cees ee 
KBs SLAVE DESIGN EXAMPLE 
DATE/ (eee B/\-BIT VERSION 
a ee | 
7 6 5 4 3 2 1 


MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 8/16-BIT VERSION 
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APPENDIX G 
MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 
8-BIT VERSION 
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8-1 


VLE6LO-NAIV 


MULTIBUS CONNECTOR, 


PI 
INT 2/ 
INT 7/ 


INIT/ 


4 
L- 


TALS@A 
JADR IA ——| 
a eeorerr 


i 
foal]. ——————yiage 
au L TALS@4 


INTERRUPT 
REQUEST 


INTERRUPT 
REQ. LATCH 


p d 7) 
(ON-BOARD DATA BUS) 
oO INTERR. |-800& 
BASE ADR SELECT/ 


WRT 


PPI WRT/ 


PPI RD/ 


RD 
®D ENB / 


ADR3 - 


D@-OT 


XNCK/SAUFT AURD 
TORC/ REGISTER ADK 2 
INIT T/O PDRTS (24 LINES) ~ 
ns Pi ko Say 
tye? Sd 
re 
ADR/ ; 
XALK / ARG ———ijND do-o1 
ADR 2 
DATQ/- DO-DT 74SG64 INIT 1/0 PORTS (24 LINES) 
DAT 7/ ‘ 
RD BD ENRL / 
SLAVE DESIGN DAAMPLE 
B-BIT VERSION 
(2 eee eee © 
7 6 5 4 3 2 1 


MULTIBUS™ SLAVE DESIGN EXAMPLE SCHEMATIC 8-BIT VERSION. 
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I. INTRODUCTION 


The iSBC 957 Intellec—iSBC 86/12 Interface and 
Execution Package contains the hardware and soft- 
ware required to interface an ISBC 86/12 Single 
Board Computer with an Intellec Microcomputer 
Development System. The iSBC 957 package gives 
the 8086 user the capability to develop software on 
an Intellec System and then debug this software on 
an ISBC 86/12 board using a program download 
capability and an interactive system monitor. The 
8086 user has all the capabilities of the Intellec sys- 
tem at his disposal and has the powerful iSBC 
86/12 system monitor commands to use for 
debugging 8086 programs. 


The iSBC 86/12 board is an Intel 8086 based proc- 
essor board which, in addition to the processor, 
contains 32K bytes of dual port RAM, sockets for 
up to 16K bytes of ROM/EPROM, a serial I/O 
port, 24 parallel I/O lines, 2 programmable 
counters, 9 levels of vectored priority interrupts, 
and an interface to the MULTIBUS™ system bus. 
The iSBC 957 package consists of monitor EPROMs 
for the iSBC 86/12 board, Loader software for the 
Intellec system, four (4) cable assemblies, assorted 
line drivers and terminators, and signal adapters. 
The iSBC 957 package provides the capability of 
downloading and uploading program and data 
blocks between an iSBC 86/12 board and an Intellec 
system. In addition, monitor commands and 
displays may be input and viewed from the Intellec 
system console. The iSBC 957 package, when used 
with the iSBC 86/12 board and an Intellec Micro- 
computer Development System, provides the user 


with the capability to edit, compile or assemble, 


link, locate, download, and interactively debug 
programs for the 8086 processor. The iSBC 957 
package and the iSBC 86/12 board form an ex- 
cellent ‘‘execution vehicle’? for users developing 
software for the 8086 processor regardless of 
whether the users are 8086 component users or 
iSBC 86/12 board users. Using the iSBC 957 pack- 
age 8086 programs may be debugged at the full 5 
MHz speed of the processor. The recommended 
hardware for the execution vehicle is an iSBC 660 
system chassis with an 8 card slot backplane and 
power supply, an iSBC 032 32K byte RAM memory 


board, the iSBC 957 package, and the iSBC 86/12 


board. 
This application note will describe how the iSBC 


957 package may be used to develop and debug 


8086 programs. First a description of the iSBC 
86/12 board will be presented. Readers familiar 
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with the iSBC 86/12 board may want to skip this 
section. Next follows a detailed description of the 
iSBC 957 package and the iSBC 86/12 system 
monitor commands. A program example of a 
matrix multiplication routine will then be presented. 
This example will contain both assembly language 
and PL/M-86 procedures. The steps required to 
compile, assemble, link, locate and debug the 
program code will be explained in detail. A typical 
debugging session using the iSBC 86/12 system 
monitor will be presented. 


II. THE iSBC™ 86/12 SINGLE BOARD 
COMPUTER 


The iSBC 86/12 Single Board Computer, which is 
a member of Intel’s complete line of iSBC 80/86 
computer products, is a complete computer system 
on a single printed-circuit assembly. The iSBC 86/ 
12 board includes a 16-bit central processing unit 
(CPU), 32K bytes of dynamic RAM, a serial com- 
munications interface, three programmable parallel 
I/O ports, programmable timers, priority interrupt 
control, MULTIBUS control logic, and bus expan- 
sion drivers for interface with other MULTIBUS- 
compatible expansion boards. Also included is dual 
port control logic to allow the iSBC 86/12 board 
to act as a slave RAM device to other MULTIBUS 
masters in the system. Provision is made for user 
installation of up to 16K bytes of read only mem- 
ory. Figure 1 contains a block diagram of the iSBC 
86/12 board and in Appendix A is a simplified 
logic diagram of the iSBC 86/12 board. 


Central Processing Unit 


The central processor for the iSBC 86/12 board is 
Intel’s 8086, a powerful 16-bit H-MOS device. The 
225 sq. mil chip contains 29,000 transistors and has 
a clock rate of 5MHz. The architecture includes 
four (4) 16-bit byte addressable data registers, two 
(2) 16-bit memory base pointer registers and two (2) 
16-bit index registers, all accessed by a total of 24 
operand addressing modes for complex data han- 
dling and very flexible memory addressing. 


Instruction Set — The 8086 instruction repertoire 
includes variable length instruction format (in- 
cluding double operand instructions), 8-bit and 16- 
bit signed and unsigned arithmetic operators for 
binary, BCD and unpacked ASCII data, and iter- 
ative word and byte string manipulation functions. 
The instruction set of the 8086 is a functional 
superset of the 8080A/8085A family and with 
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32K x8 
RAM 
DUAL-PORT 
BUS 


DUAL-PORT 
CONTROLLER 


POWER FAIL 
INTERRUPT 


16K x8 
| ROM/EPROM pen 
. * (SOCKETS) 


"* QN-BOARD INTERNAL BUS 


MULTIBUS / 
. MULTIMASTER ; 
. INTERFACE | °° 


MULTIBUS 


Gwenn 


iwrenaver 
LECTOR |» 
GUMPERS) = 


PROGRAMMABLE 
INTERRUPT 
CONTROLLER 


24 PROGRAMMABLE 
PARALLEL 4J/O LINES © 


/ .F__ORIVER/ 
TERMINATOR 
INTERFACE | 


RS232C0 
COMPATIBLE 
DEVICE 


~~” CONTROL SERIAL 
INTERFACE . DEVICE 


* RS232C | 
INTERFACE } © 


PROGRAMMABLE 
RIPHERAL 
INTERFACE 


PROGRAMMABLE’ | _ ee: ne 
COMMUNICATIONS ery ai 
poids Apis CE .| GENERATOR 


PROGRAMMABLE 


Figure 1. iSBCc™ 86 / 12 Single Board Computer Block Diagram . | 


available software tools, programs written for the 
8080A/8085A can be easily: ponvercy and run on 


the 8086 processor. 
Architectural Features — A 6-byte instruction queue 


provides pre-fetching of sequential instructions and 


can reduce the 1.24sec minimum instruction cycle 


to 400 nsec by Pee me instruction already in the 


queue. 


The stack oriented eae facilitates nested 


sub-routines and co-routines, ‘reentrant code and 
powerful interrupt handling. The memory expan- 
sion capabilities offer a 1 megabyte addressing 


range. The dynamic relocation scheme allows ease 


in segmentation of pure procedure and data for 
efficient memory utilization. Four segment: registers 
(code, stack, data, extra) contain program loaded 
offset values which are:used to map 16-bit: addresses 


to 20-bit addresses. Each register maps 64K-bytes at 


a time and activation of ‘a specific register is con- 
trolled explicitly by program control and is also 
selected’. 
instructions. . 


a by ure eons and. 
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Bus Structure 


The iSBC 86/ 12 board has an Steal bus for 
communicating with on-board memory and I/O 
options, a system. bus (the MULTIBUS) for refer- 
encing additional memory and I/ O_ options, and 
the dual-port bus which allows access to. RAM 
from the. on-board CPU and the MULTIBUS Sys- 
tem Bus. Local (on-board) accesses do not require 
MULTIBUS communication, making the system 
bus available for use by other MULTIBUS masters 
(i.e. DMA devices and other single board. com- 
puters transferring to additional system memory). | 
This feature allows true parallel processing in. a 
multiprocessor environment. In addition, the MUL- 
TIBUS interface can be used for system expansion 
through the use of other. 8- and 16-bit iSBC com- 
puters, memory and I/ O expansion boards. 


RAM Capabilities 

The. iSBC- 86/12 board contains . 30K-bytes of 
dynamic read/write memory. Power for the on- 
board RAM and refresh circuitry may be option-' 
ally provided .on an. auxiliary power. bus, and 
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memory protect logic is included for RAM battery 
backup requirements. The iSBC 86/12 board con- 
tains a dual port controller which allows access to 
the on-board RAM from the iSBC 86/12’s CPU 
and from any other MULTIBUS master via the 
system bus. The dual port controller allows 8- and 
16-bit accesses from the MULTIBUS System Bus 
and the on-board CPU transfers data to RAM over 
a 16-bit data path. Priorities have been established 
such that memory refresh is guaranteed by the on- 
board refresh logic and that the on-board CPU has 
priority over MULTIBUS requests for access to 
RAM. The dual-port controller includes independent 
addressing logic for RAM access from the on-board 
CPU and from the MULTIBUS system bus. The 
on-board CPU will always access RAM starting 
at location 00000. Address jumpers allow on- 
board RAM to be located starting on any 8K-byte 
boundary within a 1 megabyte address range for 
accesses from the MULTIBUS system bus. In con- 
junction with this feature, the iSBC 86/12 board 
has the ability to protect on-board memory from 
MULTIBUS access to any contiguous 8K-byte 
segments. These features allow multi-processor 
systems to establish local memory for'each proces- 
sor and shared system (MULTIBUS) memory con- 
figurations where the total system memory size 
(including local on-board memory) can exceed 1 
megabyte without addressing conflicts. 


EPROM /ROM Capabilities 


Four sockets are provided for up to 16K-bytes of 
non-volatile read only memory on the iSBC 86/12 
board. Configuration jumpers allow read only 
memory to be installed in 2K, 4K, or 8K increments. 


On-board ROM is accessed via 16 bit data paths. 
System memory size is easily expanded by the 
addition of MULTIBUS compatible memory boards 
available in the iSBC 80/86 family. 


Parallel I/O Interface 


The iSBC 86/12 board contains 24 programmable 
parallel I/O lines implemented using the Intel 
8255A Programmable Peripheral Interface. The 
system software is used to configure the I/O lines 
in any combination of unidirectional input / output 
and bidirectional ports. 


Therefore, the I/O interface may be customized to. 


meet specific peripheral requirements. In order to 
take full advantage of the large number of possible 
I/O configurations, sockets are provided for inter- 
changeable I/O line drivers and_ terminators. 
Hence, the flexibility of the I/O interface is further 


enhanced by the capability of selecting the appro- 
priate combination of optional line drivers and 
terminators to provide the required sink current, 
polarity, and drive/termination characteristics for 
each application. The 24 programmable I/O lines 
and signal ground lines are brought out to a 50-pin 
edge connector that mates with flat, woven, or 
round cable. 


Serial I/O 


A programmable communications interface using 
the Intel 8251A Universal Synchronous/ Asyn- 
chronous Receiver/Transmitter (USART) is con- 
tained on the iSBC 86/12 board. A software 
selectable baud rate generator provides the USART 
with all common communication frequencies. The 
USART can be programmed by the system soft- 
ware to select the desired asynchronous or syn- 
chronous serial data transmission technique (in- 
cluding IBM Bi-Sync). The mode of operation (i.e., 
synchronous or asynchronous), data format, con- 
trol character format, parity, and baud rate are all 
under program control. The 8251A provides full 
duplex, double buffered transmit and receive capa- 
bility. Parity, overrun, and framing error detection 
are all incorporated in the USART. The RS232C 
compatible interface on each board, in conjunction 
with the USART, provides a direct interface to 
RS232C compatible terminals, cassettes, and asyn- 
chronous and synchronous modems. The RS232C 
command lines, serial data lines, and signal ground 
line are brought out to a 26 pin edge connector that 
mates with RS232C compatible flat or round cable. 
The iSBC 530 teletypewriter adapter provides an 
optically isolated interface for those systems re- 
quiring a 20 mA current loop. The iSBC 530 
adapter may be used to interface the iSBC 86/12 
board to teletypewriters or other 20 mA current 
loop equipment. 


Programmable Timers 


The iSBC 86/12 board provides three independent, 
fully programmable 16-bit interval timers /event 
counters utilizing the Intel 8253 Programmable In- 
terval Timer. Each counter is capable of operating 
in either BCD or binary modes. Two of these 
timers/counters are available to the systems de- 
signer to generate accurate time intervals under 
software control. Routing for the outputs and gate/ 
trigger inputs of two of these counters is jumper 
selectable. The outputs may be independently 
routed to the 8259A Programmable Interrupt Con- 
troller and to the I/O line drivers associated with 
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the 8255A Programmable Peripheral Interface, or 
may be routed as inputs to the 8255A chip. The 
gate/trigger inputs may be routed to I/O termin- 
ators associated with the 8255A or as output con- 
nections from the 8255A. The third interval timer 
in the 8253 provides the programmable baud rate 
generator for the iSBC 86/12 RS232C USART 
serial port. In utilizing the iSBC 86/12, the systems 
designer simply configures, via software, each timer 
independently to meet system requirements. When- 
ever a given time delay or count is needed, soft- 
ware commands to the programmable timers /event 
counters select the desired function. 


The contents of each counter may be read at any 


time during system operation with simple read 
operations for event counting applications, and 
special commands are included so that the contents 
can be ready ‘‘on the fly’’. 


MULTIBUS™ and Multimaster Capabilities 


The MULTIBUS system bus features asynchronous 
data transfers for the accommodation of devices 
with various transfer rates while maintaining maxi- 
mum throughput. Twenty address lines and sixteen 
separate data lines eliminate the need for address/ 


data multiplexing/demultiplexing logic used in 


other systems, and allow for. data transfer rates up 
to 5 megawords/sec. A failsafe timer is included in 
the iSBC 86/12 board which can be used to gener- 
ate an interrupt if an addressed device does not 
respond within 6 msec. 


Multimaster Capabilities — The iSBC 86/12 board 
is a full computer on a single board with resources 
capable of supporting a great variety of OEM sys- 
tem requirements. For those applications requiring 
additional processing capacity and the benefits of 
multiprocessing (i.e., several CPUs and/or con- 
trollers logically sharing system tasks through 
communication over the system bus), the iSBC 86/ 
12 board provides full MULTIBUS arbitration 
control logic. This control logic allows up to three 
iSBC 86/12 boards or other bus masters, including 
iSBC 80 family MULTIBUS compatible 8-bit single 
board computers, to share the system bus in serial 
(daisy chain) priority fashion, and up to 16 masters 
to share the MULTIBUS with the addition of an 
external priority network. The MULTIBUS arbitra- 
tion logic operates synchronously with a MULTI- 
BUS clock (provided by the iSBC 86/12 board or 
optionally provided directly from the MULTIBUS 
System Bus) while data is transferred via a hand- 
shake between the master and slave modules. This 
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allows different speed controllers to share resources 


on the same bus, and transfers via the bus proceed 
asynchronously. Thus, transfer speed is dependent 
on transmitting and receiving devices only. This 
design prevents slow master modules from being 
handicapped in their attempts to gain control of the 
bus, but does not restrict the speed at which faster 
modules can transfer data via the same bus. The 
most obvious applications for the master-slave 
capabilities of the bus are multiprocessor configur- 
ations, high speed direct memory access (DMA) 
operations, and high speed peripheral control, but 
are by no means limited to these three. 


Interrupt Capability 


The iSBC 86/12 board provides 9 vectored interrupt 
levels. The highest level is the NMI (Non-Maskable 
Interrupt) line which is directly tied to the 8086 
CPU. This interrupt cannot be inhibited by soft- 
ware. and is typically used for signalling PSOEnIC 
events (e.g., power failure). 


The Intel 8259A Programmable Interrupt .Con- 
troller (PIC): provides vectoring for the next ah 
interrupt levels. 


The PIC accepts interrupt requests from the pro- 
grammable parallel and serial I/O interfaces, the 
programmable timers, the system bus, or directly 
from peripheral equipment. The PIC then deter- 
mines which of the incoming requests is of the 
highest priority, determines whether this request is 
of higher priority than the level currently being 
serviced, and, if appropriate, issues an interrupt to 
the CPU. Any combination of interrupt levels may 
be masked, via software, by storing a single byte 
in the interrupt mask register of the PIC. The PIC 
generates a unique memory address for each in- 
terrupt level. These addresses contain unique 
instruction pointers and code segment offset values 
(for expanded memory operation) for each interrupt 
level. In systems requiring additional interrupt 
levels, slave 8259A PIC’s may be interfaced via the 
MULTIBUS system bus, to generate. additional 
vector addresses, yielding a total of 65 unique 
interrupt levels. 


Interrupt Request Generation — incereaps requests 
may originate from 16 sources. Two jumper select- 
able interrupt requests can be automatically gener- 
ated by the programmable peripheral interface. 


Two jumper selectable interrupt requests can be 
automatically generated by the USART when: a 
character is ready to be transferred to the CPU ora 
character is ready to be transmitted. a. 
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A jumper selectable request can also be generated 
by each of the programmable timers. Eight addi- 
tional interrupt request lines are available to the 
user for direct interface to user designated peripher- 
al devices via the system bus, and two interrupt 
request lines may be jumper routed directly from 
peripherals via the parallel I/O driver /terminator 
section. 


Power-Fail Control 


Control logic is also included to accept a power-fail 
interrupt in conjunction with the AC-low signal 
from the iSBC 635 Power Supply or equivalent. 


Expansion Capabilities 


Memory and I/O capacity may be expanded and 
additional functions added using Intel MULTIBUS 
compatible expansion boards. High speed integer 
and floating point arithmetic capabilities may be 
added by using the iSBC 310 high speed mathe- 
matics unit. Memory may be expanded to | mega- 
byte by adding user specified combinations of 
RAM boards, EPROM boards, or combination 
boards. Input/output capacity may be increased by 
adding digital I/O and analog I/O expansion 
boards. Mass storage capability may be achieved 
by adding single or double density diskette con- 
trollers. Modular expandable backplanes and card- 
cages are available to support multiboard systems. 


Il. THE iSBC™ 957 PACKAGE 


The iSBC 957 Intellee—iSBC 86/12 Interface and 
Execution Package extends the software develop- 
ment capabilities of the Intellec Microcomputer 
Development systems to the Intel 8086 CPU. Pro- 
grams for the 8086 may be written in PL/M-86 
and/or assembly language and compiled or as- 
sembled on the Intellec system. These programs 
may then be downloaded from an Intellec ISIS-II 
disk file to the iSBC 86/12 board for execution and 
debug. The programs will execute at the full 5 MHz 
clock rate of the 8086 CPU with no speed degrada- 
tion caused by the iSBC 957 hardware or software. 
Special communication software allows transparent 
access to the powerful interactive debug commands 
in the iSBC 86/12 monitor from the Intellec con- 
sole terminal. These debug commands include 
single-step instruction execution, execution with 
breakpoints, memory and register displays, memory 
searches, comparison of two memory blocks and 
several other commands. After a debugging session, 
the debugged program code may be uploaded from 
the iSBC 86/12 board to an Intellec ISIS-II disk 
file. i ae 7 | 
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The iSBC 957 Intellece—iSBC 86/12 Interface and 
Execution Package consists of the following: 


a. Four Intel 2716 EPROMs which contain the sys- 
tem monitor program for the iSBC 86/12 board. 


b. An ISIS-II diskette containing loader software 
for execution in the Intellec which provides for 
communications between the user or an Intellec 
ISIS-II file and the iSBC 86/12 board. Also in- 
cluded on the diskette are a library of routines 
for system console I/O. 


c. Four cable assemblies used for transmitting com- 
mands, code and data between the iSBC 86/12 
board and the Intellec system. 


d. An iSBC 530 adapter assembly which converts 
serial communications signals from current loop 
to RS232C. 


e. Line drivers and terminators used for the iSBC 
86/12 parallel ports. 


f. A small printed circuit board which is plugged 
into an iSBC 86/12 receiver /terminator socket 
and is used when program code is downloaded 
or uploaded using the parallel cable. 


iSBC™—Intellec™ Configurations 


There are two distinct functional configurations for 
the iSBC 957 package; one configuration for the 
Intellec Series II, Models 220 or 230 development 
systems and another for the Intellec 800 series 
development systems. | 


Intellec Series If System Configurations. 


When used with Intellec Series If Model 220 or 
230 systems, a set of cables are used to connect the 
serial I/O port edge connector on the iSBC 86/12 
board and the SERIAL 1 output port on the Intellec 
system. This configuration is shown in Figure 2. 
How this system functions is explained in the fol- 
lowing paragraphs. 


The SERIAL 1 port on the Intellec Series II Model 
220 or 230 system is an RS232 port which is de- 
signed for use with a data terminal. This port may 
be used on the Intellec system for interfacing to 
RS232 devices such as CRT terminals or printers. 
The serial ports on the iSBC 86/12 board and the 
Intellec systems are connected as shown in the 
Figure 2. The flat ribbon cable connected to the 
iSBC 86/12 board has an edge connector for con- 
necting to the board on one end and a standard 
RS232 connector on the other end. The second 
cable, the RS232 Up/Down Load cable, has an 
RS232 connector on each end. This cable, however, 
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INTELLEC SERIES II 
~ MODEL 220, 230 


SERIAL PORT #1 


=~ SERIAL 1/0 
PORT 


iSBC 86 / 12 


OEM RS232-C 
CABLE 


“25232 UP / DOWN LOAD 
CABLE | | 


Figure 2. Intellec™ Series I| Model 220, 230—iSBC™ 86 / 12 Configuration 


is not a standard cable with the RS232 signals bussed 
between identically numbered pins on each of the 
connectors. The schematic for the cable is shown in 
Figure 3. Note that the TXD (transmit data) and 
the RXD (receive data) and the RTS (ready to send) 
and the CTS (clear to send) signals have been 
crossed. This is done because both the Intellec system 
and the iSBC 86/12 board are configured to act as 
data sets which are communicating with data 
terminals. Swapping these signals permits. the units 
to communicate directly with no modifications to 
the Intellec or iSBC 20F 12 systems themselves. 


(FRAME GROUND) 
(TRANSMIT DATA). 
(RECEIVE.DATA) 
(READY TO SEND) 
(CLEAR TO SEND) 


(SIGNAL GROUND) 


iSBC™ 86/12 RS232 


Figure 3. Intellec™’ — 
UP / DOWN LOAD Cable 


The software in the Intellec system accepts characters 
output from the iSBC 86/12 board through the 
Intellec SERIAL 1 port. The software then outputs 
these characters on the CRT monitor built into the 
Intellec Series II Model 220 or 230. In a. similar 
fashion, characters input from .the Intellec key- 
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board are passed down the serial link to the iSBC 
86/ 12 monitor program. The integrated CRT 
monitor and keyboard on the Intellec system then 
becomes the ‘‘virtual terminal’’ of the iSBC 86/12 
monitor program. If this were the only function of 
the iSBC 957 package, there would be no real 
benefit to the user. However, when the ‘“‘virtual 
terminal’’ capability is combined with the capa- 
bility to download and upload program code: and 
data files between the Intellec ISIS-II file system 
and the iSBC 86/12 board, a very powerful soft- 
ware development tool is realized. The software in 
the Intellec system must examine the commands 
which are input from the keyboard and in the case 
of the LOAD and TRANSFER commands (see 
later sections for details on monitor commands), 
the software must open and read or write ISIS-II 
disk files. 


Transfer rates using Intellec Series II Model 220 or 
230 system are 9600 baud when transferring hexa- 
decimal object files to or from a disk file and 600 
baud when transferring commands between the 
iISBC 86/12 board and the CRT monitor and key- 
board. With a 9600 baud transfer rate, it is pos- 
sible to load 64K bytes of menery in. about four 
minutes. , 


Intellec 800 System Configurations 


The iSBC 957 package may be used with fie fe 
tellec 800 system in four different configurations. 
These four configurations are determined by two 
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variables. The first variable is whether the iSBC 
86/12 board is connected to the Intellec 800 TTY 
port or to the Intellec 800 CRT port. The second 
variable is whether or not a parallel cable is used 
for uploading and downloading hexadecimal object 
files. Figures 4A and 4B illustrate the four 
configurations. 


In Figure 4A, the configuration shows the TTY 
port of the Intellec 800 system connected to the 
iSBC 86/12 serial port using two cables and an 
iSBC 530 teletypewriter adapter. The TTY port of 
the Intellec 800 system is designed for using a 
teletypewriter as the Intellec console device. To use 
this port for communication with the iSBC 86/12 
board, the current loop TTY signal must be con- 
verted to an RS232 compatible voltage signal. This 
function is performed by the iSBC 530 adapter. 


PARALLEL 
LOAD CABLE 
(OPTIONAL) 


4A 
INTELLEC 
MDS 800 
SYSTEM 
CRT 
4B 


INTELLEC 
‘MDS 800 
SYSTEM: 


~~=.. 


TERMINAL ee : 


The cable which connects the Intellec 800 system to 
the iSBC 530 adapter performs a function similar 
to the RS232 Up/Down Load cable described 
above. A schematic for this cable and all other 
components of the iSBC 957 package are included 
with the delivered product. | 


The transfer rate for both commands and data 
when the TTY port is connected to the iSBC 86/12 
board is 110 baud. This means to download even 
moderately sized programs would require large 
amounts of time, several minutes or even hours. 
However, much faster times may be achieved by 
using the parallel ports of the iSBC 86/12 board 
and the Intellec system for downloading program 
files. This parallel port used on the Intellec 800 
system is the output port labeled PROM which is 
normally used with the Universal Prom Pro- 


‘PARALLEL |/ 0 
PORT 


SERIAL 1/0 
PORT 


A 


iSBC 86/12 
BOARD . 


TO RS232-C 
TERMINAL 


OEM RS232-C 
CABLE 


cas ae | 


TTY ADAPTER 


SERIAL 
1/0 PORT 


PARALLEL 
’ LOAD CABLE 
(OPTIONAL) 


iSBC 86/12 


OEM RS232-C 
CABLE 


~~ RS232 UP / DOWNLOAD 
CABLE. 


Figure 4A, 4B. Intellec™ 800—iSBC™ 86/12 Configurations 
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grammer. A cable is connected between the In- 
tellec PROM port and the parallel I/O port, J1 of 
the 1SBC 86/12 board. Parallel port B of the iSBC 
86/12 board is used for the 8-bit byte transfers 
from the Intellec system to the iSBC 86/12 board, 
port A is used for the byte transfers from the iSBC 
86/12 board to the Intellec system and port C is 
used for controlling the byte transfers. A special 
status adapter piggyback board must be inserted 
into a receiver /terminator socket of the iSBC 86/12 
board. This status adapter circuit is required to 
provide the necessary handshaking signals from the 
iSBC 86/12 parallel ports to the Intellee PROM 
port. 

The transfer rate achieved vhen Gswalondnie and 
uploading hexadecimal object files with the parallel 
cable is approximately 1,000 bytes per second. The 
time required to load 64K bytes of memory is 
approximately 2'% minutes. 


Figure 4B shows a configuration with the Intellec 
800 CRT port connected to the serial port of the 
iSBC 86/12 board. The TTY port of the Intellec 
800 system is connected to a teletypewriter or some 
other current loop device to act as a system con- 
sole. The optional parallel load cable is also shown. 
The cables used for this configuration are the same 
as those used with the Intellec Series I] Configur- 
ations. Command transfer rates require 110 baud 
because the TTY port of the Intellec 800 system is 
used for communicating with the console device. 
However, hexadecimal object files can be loaded at 
9600 baud since this operation uses only the Intellec 
to iSBC 86/12 RS232 link. 


It is also possible to download files with the parallel 
cable, this mode being somewhat faster than the 
serial download mode (2% minutes versus four 
minutes for 64K bytes of memory). Table I con 
tains a summary of the command and memory 
transfer rates for each of the Intellec-iSBC 86/12 
configurations. 


Comparing the Intellec 800 configurations shown in 
Table 1 and in Figures 4A and 4B it should be 
noted: | 


1. Using the TTY port (Figure 4A) of the Intellec 
800 system for communications with the iSBC 
86/12 board (essentially) requires installation of 
the parallel cable and jumper modifications for 
downloading and uploading files, and thus, pre- 
vents the use of the parallel ports for other I/O 
functions. 


2. Using the CRT port Figure 4B) of the Intellec 
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~ 800 system for communication with the iSBC 
— 86/12: board provides for a fast serial download 
capability, thus freeing the parallel ports for 
other uses. However, this configuration requires 
a teletypewriter or a CRT capable of accepting 
-a current loop input signal as the Intellec system 

— console. | 


Table 1 : 
COMMAND AND MEMORY TRANSFER RATES FOR 
INTELLEC—iSBC™ 86 /12 CONFIGURATIONS | 


INTELLEC 


SERIES 11 220/230 INTELLEC 800 INTELLEC 800 
SERIAL PORT TTY PORT CRT PORT 


TO iSBC 86 / 12. TOiSBC 8/12 TO iSBC 86/12 — 
Effective Se eae 
Command Rate 600 Baud: 110 Baud. ‘110 Baud*.. - 
Load / Transfer 
Rate 
Serial 9600 Baud 110 Baud 9600 Baud 
Parallel N/A 1K bytes/sec** 1K bytes/sec** 
Approximate Time 
to load 64K bytes 
of memory pe 
Serial 4 minutes 5 hours 4 minutes 
Parallel N/A 2.5 minutes 2.5 minutes 


*The actual baud rate of the Intellec—iSBC 86/12 link is 9600 baud, but the effective 
command rate is determined by the slower Intellec— console serial link. 
**Transmission rate over the parallel link is determined by the speed of the two processors 
and is approximately 1K bytes per second. ; 


IV. THE iSBC 957—iSBC 86/12 MONITOR 


~ PROGRAM 


The iSBC 86/12 monitor program is an EPROM 
resident program which facilitates debugging of 
user written programs. The monitor program used 
in the iSBC 86/12 board with the iSBC 957 pack- 
age is the same monitor program written to inter- 
face the iSBC 86/12 directly to an RS232C data 
terminal. When interfaced directly to a terminal, 
the iSBC 86/12. board functions in a stand-alone 
environment communicating directly with the user 


via the data terminal. A user may use the monitor 


for entering small programs in hexadecimal format, 
executing a program, examining registers and 
memory contents, etc. 


To use the monitor program with an Intellec system, 
the proper cables must be installed and the iSBC 
957 Loader program must be loaded into Intellec 
memory and executed. The Loader program is resi- 
dent on a file named SBC861, and when executed, 
the Loader outputs a sign-on message. Next, the 
iSBC 86/12 monitor program must be started and 
the baud rate of the iSBC 86/12 to Intellec serial 
communications link must be determined. This is 
done by pressing the RESET switch on the chassis 
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Table 2 
MONITOR COMMAND LIST 


COMMAND FUNCTION AND SYNTAX 
L Load Hex Loads hexadecimal object file from Intellec into iSBC 
Object File 86/12 memory using serial (S) or parallel (P) mode. 


L {s | P} < filename>[,<bias addr>|<cr> 


T Transfer Hex Transfers blocks of iSBC 86/12 memory to Intellec as 


Object File a hex object file using serial (S) or parallel (P) mode. 
TIX] {8|P) <start addr>,<end addr>,<filename> 
[,<exec addr>}<cr> 

E Exit Exits the loader program and returns to ISIS. 
E<cr> 

N Single Step Executes one user program instruction. 
Ni<addr>],[[<addr>],[*<er> 

G Go Transfers control of the 8086 CPU to the user program 


with up to 2 optional breakpoints. 
Gl<start addr>][,<break 7 addr> 
[,<break 2 addr>) \<cr> 


S Substitute 
Memory 


Displays/modifies memory locations in byte or word 
format. 


S(W)<addr>,[ [new contents],|*<cr> 


X Examine/Modify 
Register 


Displays/modifies 8086 CPU registers. 
X[<reg>] {[<new contents >],]*<er> 


D Display Memory Displays contents of a memory block in byte or word 


format. 
D(W<start addr>[,<end addr>)<er> 


M Move Moves contents ofa memory block. 
M<start addr>,<end addr >,< destination addr><cr> 
C Compare Compares two memory blocks. 
C<start addr>,<end addr>,<destination addr><cr> 
F Find Searches a memory block for a byte or word constant. 


F[W]< start addr>,< end addr>,< data><cr> 
H Hex Arithmetic Performs hexadecimal addition and subtraction. 
H<data 1>,<data 2><cr> 


Port Input 


Inputs and displays byte or word data from input 
port. 
I[W]< port addr >,[,]*<er> 

O Port Output Outputs byte or word data to output port. | 


O[W)<port addr>, <data>[,<data>)*<cr> 


Syntax conventions used in the command structure are as follows: 
[A] indicates that ‘‘A’’ is optional 
{[A]* indicates one or more optional iterations of “A” 
<B> indicates that ‘’B”’ is a variable 
{Alp} indicates “A” or “B” 
<Cr> indicates a carriage return is entered 
Numeric arguments can be expressed as a number, the contents of a register, 


or the sum or difference of numbers and register contents. Thus, addresses 
and data can be expressed as follows: 


addr ::= = [<expr>:]<expr> 
expr i= <number>|<register>|<expr> {+1-} <number>| 
-<expr> {+ | -\ <register > 
register ::= AX|BX|CX|DX|SP|BP|SI|DI|CS|DS|SS/ES|IP|FL 
number ::= <digit>|<digit><number > 
digit ::= —0|1|2|3]4|/5|/6|7/8|/9|A|B|C|D|E|F 


Numeric fields within arguments are entered as hexadecimal numbers. The 
valid range of numerical values is from OOO0-FFFF. Larger numbers may be 
entered, but only the last four digits (or two in the case of byte values) are 
significant. Leading zeros may be omitted. 


An address argument consists of a segment value and an offset value separ- 
ated by a colon (:). If a segment value is not specified, the default segment 
value is the CS register value. ms 
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containing the iSBC 86/12 board and typing two 
*“U’’s on the Intellec console. The ASCII uppercase 
character U has a binary pattern of alternating ones 
and zeros, the iSBC 86/12 monitor uses this pattern 
to determine the baud rate of the serial link. After 
the baud rate has been determined, the monitor 
program outputs a sign-on message to the console. 
An example of loader program execution and 
monitor program initialization is shown below (user 
entered characters are underlined). 


:F1:SBC861 

ISIS-II iSBC 86/12 LOADER, Vx.x 

(user resets iSBC 86/12 board and types two ‘‘U’’s) 
iSBC 86/12 MONITOR, Vy.y 


The monitor prompts with a period ‘‘.’? when it is 
ready for a command. The user can then enter a 
command file, which consists of a one- or two- 
character command followed by zero, one, or more 
arguments. The command may be separated from 
the first argument by an optional single space; a 
single comma is required as a delimiter between 
arguments. The command line is terminated by a 
carriage return or a comma depending on the com- 
mand, and no action takes place until the command 
terminator is sensed. The user can cancel a com- 
mand before entering the command terminator by 
pressing any illegal key (e.g., rubout or Control-X). 


Table 2 contains a summary of the loader and 
monitor commands. These commands will not be 
explained in detail; instead, the next section of the 
application note will show examples of using these 
loader and monitor commands. The iSBC 957 
User’s Guide referenced at the front of this docu- 
ment does, however, contain a complete description 
of each of the monitor and loader commands. 


Table 3. contains a list of the 8086 hardware registers 
and abbreviations used by the monitor program. 


Table 3 . 
8086 CPU REGISTERS 


REGISTER NAME ABBREVIATION 


Accumulator 
Base 

Count 

Data 

Stack Pointer 
- Base Pointer 
Source Index 
Destination Index 
Code Segment | 
Data Segment 
Stack Segment 
Extra Segment 
Instruction Pointer 
Flag 
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- Figure 5. Memory Map of iSBC™ 86/12 Memory With Monitor Program 


Figure 5 contains a memory map of the iSBC 
86/12 memory with the monitor program. Note 
that the monitor uses the top 8K bytes of memory 
for: its program code and the first 384 bytes of 
memory (locations 9 hex to 17F hex) for monitor 
and user stack, data and interrupt vectors: When 
the monitor program is reset, the segment registers, 


the IP and the flags are set to ;and the SP is’ set 
to $1CQH allowing’ 64 bytes for the user’s stack. If 


64. bytes is not sufficient for thé user’s application 
program, the SP should be set to some other value. 
The monitor’ program sets the single-step, one-byte 
instruction trap and non-maskable interrupt vectors 
to monitor entry points. The monitor also sets the 
8259A Priority Interrupt Controller to fully nested 
mode with level @ at-the highest priority and all 
interrupts unmasked. The eight interrupt vector 
addresses for the 8259A are also set to addresses in 
the monitor. User programs may change the 8259A 
interrupt vectors to interrupt service routine ad- 
dresses within the user programs; it is not necessary 
for users to program the 8259A chip directly. When 
an interrupt occurs, control passes to either the 
monitor or directly to user code depending on the 
address stored in the vector location. When the 
monitor responds to an interrupt, it acknowledges 
the interrupt and displays the interrupt level, CS 
and IP register values and next instruction byte on 
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the system console (e.g., 1=3 @ 100:230F F%5). 
When a user requests a breakpoint with a ‘‘G”’ 
command, the monitor inserts the single byte 
instruction trap instructions (INT 3) in the location 
where the breakpoint is requested. It is also possible 
for the user to code an INT 3 instruction in his 
program. When a user coded INT 3 instruction is 
executed, the monitor will be re-entered and a line 
with the format @<CS Value>:<IP Value> <In- 
struction byte> will be displayed (e.g., @ 1200:3FO2 
F5). be dss 

Included on the diskette with the Loader program 
are two libraries containing I/O routines for the 
console. The library files are named SBCIOS.LIB 
and SBCIOL.LIB; they contain similar routines. 
The routines in SBCIOS.LIB are written to be 
called with intrasegment subroutine calls, a PL/M- 
86 module compiled with the ‘‘small’’ control 
generates this type of call. The routines in 
SBCIOL.LIB are written to be called with interseg- 
ment subroutine calls, a PL/M-86 module com- 
piled with either the ‘‘medium”’ or “‘large’’ control 
generates this.type of call. , 

The console input output routines, CI and CO, 
contained in the library should be used when per- 
forming character input and output on the console. 
Example PL/M-86 calls to the two routines are: 
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CI: PROCEDURE BYTE EXTERNAL; 


END CI; 


CO: PROCEDURE (X) EXTERNAL; 


DECLARE X BYTE; 
END CO; 


DECLARE INPUT$CHAR, 


OUTPUT$CHAR BYTE; 


INPUT$CHAR = CI; 


CALL CO(OUTPUT$CHAR); 


General Comments on Use of the iSBC 957 Package 


1. 


If the iSBC 86/12 board is reset any time after 
the initial baud rate search, it is not necessary to 
reload the iSBC 957 Loader program or to 
download the program code a second time to the 
iSBC 86/12 board. It is only necessary to re- 
establish the communications link by typing two 
*‘U’’s for the baud rate search. 


. The iSBC 86/12 board should not be plugged 


into an available card slot in an Intellec chassis; 
a separate chassis should be used. There are at 
least three reasons for this: 


a. There is only one RESET signal available on 
the Intellec system bus. Thus, each processor 
may not be reset independently. This means 
that the iSBC 86/12 board cannot be reset 
without re-booting the ISIS-II operating sys- 
tem and restarting the iSBC 957 Loader. 


b. The Intellec system uses five of the eight avail- 
able interrupts on the system bus. This severely 
restricts the range of interrupts available to 
the iSBC 86/12 board. Also, the iSBC 86/12 
board cannot turn-off the interrupt lamps on 
the Intellec front panel. 


c. The iSBC 86/12 board may address up to 1 
Megabyte of memory using a 20 bit address. 
- Many Intellec systems contain boards which 
generate and decode only the low order 16 
address bits. For example, the iSBC 016 mem- 
ory expansion board and the Intellec 800 
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monitor PROMs only decode 16 address bits. 
Memory expansion above 64K bytes in these 
systems is difficult since the boards which de- 
code only 16 bits will force ‘‘holes’’ in the 
address space above 64K. 


. The iSBC 86/12 board is delivered with two 


inputs to the 8259A Priority Interrupt Controller 
connected. Interrupt request 2 (IR2) is connected 
to the counter 9 output of the 8253 Program- 
mable Interval Timer. IRS is connected to the 
INTS/signal of the MULTIBUS System Bus. If 
these interrupts are not desired, the wire wrap 
jumpers making the connections should be re- 
moved from the iSBC 86/12 board. A particular 
problem may exist with the counter % connection 
to IR2. If the 8253 counter @ is not specifically 
initialized with software, a low frequency square 
wave output will exist at counter Bs output. This 
may cause unwanted interrupts when interrupts 
are enabled by user programs. 


4. If the iSBC 86/12 board is used in a system with 


expansion boards, it is important that the MUL- 
TIBUS bus exchange pins be properly jumpered. 
For example, if the iSBC 86/12 board is used 
with an iSBC 032 expansion memory board in a 
system, the BPRN/ MULTIBUS pin for the 
iISBC 86/12 board should be grounded. 


In addition, if any interrupts are used with the 
iSBC 86/12 board the BPRN/ pin must be 
grounded. This is true in both single and mul- 
tiple board systems. 


. Certain user systems require more than one single 


board computer in the system for performing the 
functions required by the application. The MUL- 
TIBUS System Bus has been specifically designed 
to permit multiple CPU boards to communicate 
and to share system resources. However, de- 
bugging systems with multiple CPUs has always 
posed somewhat of a problem. The iSBC 957 
package provides a solution to this problem. The 
serial cable which connects the iSBC 86/12 
board to the Intellec system may be removed 
after the program has been downloaded to the 
iSBC 86/12 board. A console CRT may then be 
connected directly to the iSBC 86/12 board and 
the monitor program may be used to debug the 
program running on the board. Other iSBC 
86/12 boards may also be downloaded from the 
Intellec system and then switched to their own 
local terminals. An 8-bit processor board, such 
as the iSBC 80/30 board, may also be included 
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in the system and ICE-85™. may be used for 
debugging the iSBC 80/30 program concurrently 
_ with the iSBC 86/12 programs. 
_ scheme, it is possible to debug a system which 
has several CPU boards by. setting breakpoints 
and using other debugging features | on oot of 
. _ the individual CPUs. 


v. MATRIX MU LTIPLICATION EXAMPLE 


To illustrate how the iSBC 957 package can be used 
to assist in the writing and debugging of 8086 pro- 
grams on the iSBC 86/12 board, an example pro- 
gram of a matrix multiplication will be presented. 
The example chosen has been intentionally kept 
simple and straightforward. The emphasis: of this 
section will be to document the steps required to as- 
semble, compile, link, locate and debug software 
using an Intellec system, the iSBC 957 package and 
the iSBC 86/12 board. Part of the example will be 
written in 8086 assembly PUN AES: and part in PL/ 
M-86. 


The main program is written in PL/M-86. The 
main program first performs some initialization 
and the matrix multiplication, then the program 
calls an assembly language procedure (subroutine), 
a PL/M-86 procedure and the console output pro- 
cedure CO supplied in the I/O library on the iSBC 
957 diskette. A flow diagram for the example 
program is shown in Figure 6. 


Explanation of the Program Code 


The program code is contained in three Sanwa 
modules EXECUTION$VEHICLE, FIND, and 
SBCCO. EXECUTION$VEHICLE contains the 
main program coded in PL/M-86 and the binary 
to ASCII conversion procedure BIN$SDEC$ASC 
also coded in PL/M-86. The module FIND con- 
tains the assembly language. procedure ‘FIND$MX 
which searches a matrix for its maximum value. 
The module SBCCO resides in the library of con- 
sole I/O routines supplied with the iSBC 957 pack- 
age. The procedure CO will be used from this 
library. 


The program mee for the EXECUTIONSVEHICLE 
and FIND modules will be explained in the follow- 
ing paragraphs. Appendix B contains compilation 
and assembly listings for: the two. modules; also 
contained in Appendix B is.a memory and debug 
map for the linked modules. The listings contain 
circled reference letters (e.g., (A)) which are referred 
to by the code description below. The listings in the 
appendix have been printed on. fold-out pages so 
that they may easily be seen when reading the text. 


Using this — 
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Initialize 
XSROW & YSROW 
Matrices 


Muitiply 
Matrices, 
store result in 
ZSROW 


Find MAX value 
in ZSROW 


BINSDECSASC : 


Convert to 
ASCII 


Output MAX 
value on 
terminal using 
CO routine . : «| 


Figure 6. . | 
Flow Diagram of Matrix Multiplication Example — 


Much of the description given below assumes that 
the reader is familiar with the PL/M-86 language 
and compiler, the 8086 assembler, and the link and 
locate program QRL86. It is recommended that the 
reader have at least a cursory knowledge of these 
subjects. The Intel: literature for these subjects is 
listed near the front of this application note. 


The EXECUTIONSVEHICLE Module 


(A) The first section of the module includes intro- 


ductory comments and then statements to de- 
clare the matrices, other variables, and pro- 
cedures used in the program. Note that the 

_ matrix dimensions are declared using the literals 
M, N, and. P which are initially set to 6, 5, and 
3. Later in this note, other values for M, N, 
and P will be used. | 


The- next. section oe code contains the state- 
ments which initialize the two. matrices that will 
_. be multiplied X$ROW and Y$ROW. 


- As a result of this initialization, the two ma- 
trices will contain values as shown in. Figure 7. 
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3 3 
4 4 
5 5 
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XSROW (6X5) YSROW (5X3) 


Figure 7. 
X$ROW and YSROW Matrices After Initialization 


© The next program section performs the matrix 


multiplication. The algorithm required to mul- 
tiply two matrices X and Y, storing the result in 
a third matrix Z is: 


n 
Zmp = > Xmi *Yj 
ie | 

Assuming X to be 6X5 matrix and Y a 5X3 
matrix then 

Ly = XY + XpVo + Xz Vo) + XyyXy + Xs V5 
Thus, the upper left term is equal to the sum of 
the products of the top row of the X matrix 
times the left column of the Y matrix. The re- 
sult that is obtained by multiplying the two 
matrices X$ROW and Y$ROW after they are 


initialized as explained above, is shown in 
Figure 8. 


0 0 0 
0. «5 “=40 
0  =10° =20 
0 -15 -30 
0 -20 -40 
0 -25. -50 
ZSROW (6X3) 


Figure 8. Result of Multiplying the Initialized Matrices 


X$SROW and YSROW 


(D) The external assembly - language procedure 
FIND$MxX is called to determine the maximum 
value in the matrix. The procedure is a typed 
procedure and returns the maximum value to 
the calling program which stores it in the i inte- 
ger variable MAX. 


() The maximum value is then converted to a six 
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(6) digit ASCII character string by the pro- 
cedure BINSDEC$ASC. The character string is 
stored in the array MAX$ASC$ARRAY, which 
contains the sign of the number and five (5) 
digits for the magnitude. 


Finally, the characters “MAX VALUE ="’ are 
output on the system console followed by the 
6 ASCII characters containing the maximum 
value. The PL/M-86 built-in procedure SIZE 
returns the number of bytes of the array TEXT 
as a word value. The PL/M-86 built-in pro- 
cedure SIGNED changes the type of the value 
from WORD to INTEGER. This is required so 
that the type of the arguments in the DO state- 
ment agree. The console output procedure CO 
is used to output the characters on the eye 
console. 


G) Also contained in the module MATRIX.PLM 


is the binary to ASCII conversion procedure 
BINSDECS$ASC. The first portion of the. code 
contains the comments explaining the para- 
meters and the calling sequence followed by the 
declarations. Note that the address of the array 
where the characters are to be stored is passed 
to the procedure and that the characters will be 
stored in the array using based variables. The 
next section of the code stores either a + or — 
sign in the first character position of the ASCII 
array and stores the absolute value of VALUE 
in the variable TEMP. Finally, the binary value 
is converted to ASCII using the algorithm 
explained in the comments. The MOD operator 
returns the remainder of the division by 10. The 
UNSIGN built-in procedure is required to 
change the type of the expression from INTE- 
GER to WORD. 


The FIND Module. 
(H) The FIND module contains the assembly lan- 


guage procedure FINDMX. The calling - se- 
quence and the parameters are explained in the 
comments at the beginning of the listing. Note 
that the label FINDMX has been declared 
PUBLIC so the link program can fill in its 
address in the CALL statement in the main 
program of module EXECUTIONS$VEHICLE. 


The FIND module will contain three segments: 
a data segment, a stack segment and a code 
segment. It will be both convenient and prag- 
matic to append these three segments to the 
code, data and stack segments created by the 
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~~ tion codes. 


compiler for the EXECUTION$VEHICLE 


- module. To accomplish this, the three segments 

must be given the same: SEGMENT and CLASS 
Names as those given these segments by the 
compiler. The SEGMENT and CLASS names 


cused by the compiler are CODE, DATA, and . 
_- STACK. The GROUP statements are used to 


. place the segments DATA and STACK in the 
~ group DGROUP and the segment CODE in the 
-. group CGROUP. These group definitions con- 
_ form with the group definitions generated by 


— the PL/M-86 compiler when the SMALL size 


control option is used. A group is a collection 
of segments which requires less than 64K bytes 
_ of memory. 


The ASSUME directive aroun the assembler 


that the DS and SS registers will contain the 
base address of DGROUP and the CS register 


will contain the base address of CGROUP.- 


This information will be used by the assembler 
when constructing machine instructions. 


} The first segment appearing in the module is 
- the data segment. The order of the segments is 
arbitrary, although it is recommended that the 


~~ data segment-precede the code segment to mini- 
_ mize forward references to variables which may 


cause the assembler to generate longer instruc- 
7 The data segment is ‘declared 
_ PUBLIC, aligned on a WORD boundary and 


given both a segment and class name of DATA. 
Then follows the contents of the segment. In 


— this particular example, only one word of stor- 


age is required. The ENDS directive indicates , 


the end of the segment. 


Next < comes the stack segment andi is given 
the segment name of STACK, the combine- 
type attribute of STACK and the class name of 


.. STACK. The combine-type attribute of STACK 


. assures that the stack storage required in this 
- module will be appended to the storage re- 
quired in the PL/M-86 compiled modules. Two 
bytes of stack are required by the code in this 
- module, however, the monitor uses 13 words of 
stack when breakpoints and interrupts are used. 
~ Therefore, 14 words are reserved for the stack. 


Finally comes the code segment. The code seg- 


‘ment has been given a segment name and class 


name of CODE and a group name of 
CGROUP, and has been declared PUBLIC. 
The alignment attribute of BYTE is specified 
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since it is desired that the code from this 
module be appended directly to the code from 
other modules without gaps between the code 
modules. 


The assembly language code follows next. The 
code for the procedure must be enclosed be- 
tween a pair of PROC, ENDP statements. The 
PROC statement is given the label FINDMX 
and specified as a NEAR procedure indicating 
it will be called with a near (intra-segment) 
CALL instruction and not a far (inter-segment) 
CALL instruction. 


The comments at the beginning of the module 
and adjacent to the program statements ex- 
plain the function being performed by the 
assembly language code. 


The SBCCO Module 


(M) The console output procedure CO is contained 
in the object module SBCCO of the library file 
SBCIOS.LIB. SBCIOS.LIB is part of the iSBC 
957 package I/O libraries. The calling sequence 
and parameters for CO may be seen in the 
external procedure declaration in the EXE- 
CUTION$VEHICLE module. 


Compiling the EXECUTIONSVEHICLE 
Module | | 
The EXECUT IONSVEHICLE weaules i Sared on 
a file named MATRIX.PLM on disk device :F1:. 
To compile the module, the following command 
line is used: | 


— PLM86 :F1: MATRIX. PLM DEBUG 


This command line will cause the module stored in 
the file :Fl:MATRIX.PLM to be compiled. The 
object code generated will be stored in a file with 
the default name :F1:MATRIX.OBJ and the listing 
generated will be stored in a file with the default | 
name :Fl:MATRIX.LST. To override the default 
object and listing files, the NOOBJECT and NO- 
LIST compiler control switches can be used. File 
names for the listing and object files may also be 
specified in the command line. The DEBUG com- 
piler control switch causes the compiler to generate 
extra symbol and line number information which 
will be used during debugging of the program. A 
listing of the compiled EXECUTION$VEHICLE 
module is contained in Appendix B. 


To aid in the debugging of the program, the 
module was compiled ‘a second time with the fol- 
lowing command line: 7 
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— PLM86 :Fl:MATRIX.PLM NOOBJECT 
CODE DEBUG PRINT (:F1:MATRIX.XLS) 


This command line specified that no object file is to 
be created and a listing file should be stored in the 
file :F1:MATRIX.XLS. The CODE compiler con- 
trol switch causes the compiler to list the assembly 
language statements which the compiler has gener- 
ated for each line of PL/M code. The listing stored 
in the file MATRIX.XLS is contained in Appendix 
Cc. 


Assembly of the FIND Module 


The assembly language module FIND is stored on a 
file named FIND.ASM, to assemble this module 
the following command line is used: | 


ASM86 :F1:FIND.ASM DEBUG 


This command line will cause the FIND module to 
be assembled with the object code stored in the 
default file :F1:FIND.OBJ and the listing stored in 
the default file :Fl1:FIND.LST. The listing of the 
assembled FIND module is contained in Appendix 
B. 


Linking and Locating the Object Module 


To link and locate the object modules, the QRL86 
program will be used. The QRL86 program per- 
forms both the linking and the locating of the 
object modules in a single step. QRL86 is primarily 
designed for the debugging stages of program devel- 
opment. Some applications may require the extended 
capabilities’ of the separate LINK and LOCATE 
programs when the final link and locate is per- 
formed. The command line used to invoke the 
QRL86 program is: 


QRL86 :F1:MATRIX.OBJ, :F1:FIND.OBJ, 
SBCIOS.LIB ORIGIN (1000H) 


This command line will cause QRL86 to link the 
code from the three modules and to locate the 
resultant absolute object module starting at location 
1000 hexadecimal. The iSBC 86/12 monitor uses 
the first 180H bytes of memory for the monitor 
stack, data and interrupt vectors, OOOH was chosen 
as a convenient starting address for the program. 


The absolute object code will be stored in a default. 


file :F1:MATRIX (note no file name extension is 
used). By default, the memory and debug maps 
which are generated are stored in the file :F1:MA- 
TRIX.MPQ and are contained in Appendix B. 


The memory map contains the starting  ad- 
dresses and sizes of the CODE, CONST, 
DATA, STACK and MEMORY segments of 
the object module. Note that the start address 
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for the program is specified as (G199H, $02H) 
indicating a CS value of $199H and an IP 
value of $092H or an absolute value of $1002H. 
The first two bytes of the code segment contain 
address values which the code generated by the 
compiler will use for setting up the DS and SS 
registers. The memory map shows the code 
segments from the. three modules collected into 
the group CGROUP. The code segment from 
the EXECUTION$VEHICLE module is given 
the segment and class names of CODE and is 
put into CGROUP by the PL/M compiler. To 
assure that the code segment from the FIND 
module is concatenated with the code segment 
from the EXECUTION$VEHICLE module the 
identical class, segment and group names were 
specified in the SEGMENT and GROUP state- 
ments in the FIND module. Next, the group 
DGROUP is shown in the memory map. 
DGROUP contains 4 segments labelled 
CONST, DATA, STACK and MEMORY. 
Putting all of these segments in the same group 
tells the linker that they will all be in the same 
64K block of memory. The SMALL size con- 
trol option of the compiler, which was invoked 
by default, creates CGROUP, DGROUP, and 
the segments contained in them. er 
The debug map contains the memory address 
of variables, instruction labels and the ad- 
dresses of each code line of the PL/M-86 
module. Notice that the variable storage labels 
_ have their addresses specified in the format (DS 
register value, displacement). For example, the 
variable TEMP has an address of DS=912AH, 
displacement = 0@O0CH or an absolute address 
of $136H. Instruction labels and line numbers 
use the format (CS register value, IP register 
value). Thus, line number six (6) in the module 
EXECUTION$VEHICLE has the address 
CS=9169H, IP=@B5H or 911B5H. 


Object to Hex Conversion 


Before downloading the program to the iSBC 86/12, 
the format of the object module must be converted 
from the absolute object module format which 
QRL86 creates to a hexadecimal/ASCII representa- 
tion of the object module. This is done using the pro- 
gram OH86 with the following command line: 


OH86 :F1 :MATRIX TO :Fl:MATRIX.HEX 
Downloading and Debugging the Program 


The hardware configuration used for debugging the 
matrix multiplication example program code was 
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an Intellec Series II Model 230: development sys- 
tem, the iSBC 957 package, an iSBC 86/12 board, 
and an iSBC 660 system chassis. What follows is 
the eg ounce Aor a boa cevUEeE 
session. 


The first step required is to bootstrap load the. 


ISIS-II operating system by hitting the RESET 
switch of the Intellec. The Intellec resident loader 
software is then loaded and executed. Throughout 
the dialog which follows es oe ee 
ters will be underlined: 


ISIS-II, V3.4 
-SBC861 


ISIS-II ISBC 86/12 LOADER, V1.2 

To initialize the iSBC 86/12 monitor, the user must 
hit the RESET switch on the iSBC 660 chassis and 
type two ‘‘U’’s on the system console. The monitor 
program will output a line on the console when it is 
properly initialized. 


ISBC 86/12 MONITOR, V1.2. 


The monitor command “*X%’’ is typed to. check that 
the monitor is properly operating and to examine 
the contents of the 8086 registers. 

oX 


AX=0000 BX=0000 CX=0600 DX=0000 SP=01C0 BP=0000 SI=0000 
DI=08008 CS=0009 DS=0000 SS=8900 ES=0000 IP=0000 FL=0006 


To download the hex object file to the iSBC 
86/12, the ‘‘L’’ command is used. Because an 
Intellec Series I Model 230 is being used, a Serial 
download is specified. The hex file name is 
yeESes HEX which is Tesident on disk device 
“Fl: 


S,:F1l:MATRIX, HEX 


The ‘“X’? command is used again to examine the 
‘CPU registers. Note that the monitor has changed 
the contents of the CS and IP registers to the value 
of the starting address of the program. 


x 
AX=0608 BX=6400 CX=0908 DX=@068 SP=41CH BP=0000 SI=0000 
DI=8608 CS=6196 DS=0998 SS=6000 ES=0800 IP=9902 FL=0000 


The ‘‘D’’ command is next used to display the first 
101 bytes of the program code. Unless another seg- 
ment register is specified, the display command 
assumes all addresses specified are relative to the CS 
register. Thus, the code displayed will be from abso- 
lute addresses 1000 through 1100. The program code 
displayed may be compared with program code gen- 
erated by the PL/M-86 comput shown in acres 
C, code line 36. 
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The PL/M-86 compiler ends the main program in 
the EXECUTIONS$VEHICLE module with a halt 
instruction. After execution of the program it is 
more desirable to return to the monitor. To ac- 
complish this, an INT 3 instruction (code=CC) 
will be substituted for the halt instruction (code= 
F4) at the address of 1B4H relative to a CS value 
of 100H. First the “‘D’’ command is used to verify 
the address of the halt instruction, then the ‘‘S”’ 
command is used to. change the instruction to an 
INT 3 instruction. 


+S1B4, F4- CC 


To execute the PL/ M-86 main program, the “‘G” 


command is used. After the ‘‘G’’ is typed, the 


current contents of the IP are output, followed by 
the contents of the byte pointed to by the IP. A 


_ new value for the IP or breakpoint addresses may 
be specified before a carriage return <CR> is typed. 


In this example, only a <CR> is typed. 


-G W002- FA 


MAX VALUE = -@0@5@ 
@0160:61B5 55 


The program executes and outputs the maximum 
value of the matrix calculated. The INT 3 instruc- 
tion is executed which causes a return to the 
monitor. The monitor types out an at-sign (@) 
followed by the CS and IP register values and the 
first byte of the instruction following the INT 3 
instruction. 


The ‘‘X’’ command is typed to examine the CPU 
registers. Note that the program has set both the SS 
and DS registers to @12A. (@12AQH is the address 
of the DGROUP as shown in the memory map.) 


oX ’ 
AX=0030 BX=0005 CX=000A DX=G000 SP=00D0 BP=@0DG S1=G00: 
DI=6086 CS=0199 DS=012A SS=012A ES=0000 IP=01B5 FL=F20z 


The three matrices are displayed. Note that a word 
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display has been specified by using the ‘‘DW’”’ 
Command and that the addresses have been speci- 
fied relative to the DS register. The addresses of 
X$ROW, Y$ROW, and Z$ROW may be found in 
the debug map given by QRL86. Note that the 
values stored in the matrices are the same as those 
shown in Figures 8 and 9. 
.DW_DS:10,4A 
6810 BBGB BHOB 
0020 0601 8681 


0430 6403 8063 
0048 0004 0805 


6660 
0862 
6603 
0685 


0608 
2802 
0943 
6805 


OB82 
6962 
0604 
8065 


6081 
60G2 
0064 
8085 


6061 
0062 
0084 


W001 
8803 
6804 


-DW DS: 4C,68 


O04C O0O8 FFFF 
0050 FFFE 0006 
0060 FRFF FREE 


FFFF 
0000 


FFFE 
FREE 


BOUO 
FFFE 


FFEFF FFFE 0686 


-OW DS:6A,8C 

O06A BHBH GUBY 
0070 60800 FFFB 
W080 FFE2 88080 


OB00 
FFF6 
FFEC 


6006 
FFD8 


FFF6 
a) 


BYOB 
FFCE 


FEEC 
FFE7 


FFF 


The ‘‘G’’ Command is used to reset the IP register 
to the start address of the program (92) and to 
specify a breakpoint at address QAEH, which is the 
address of statement 57 of the main program. 
Statement 57 is the point in the program after the 
X$ROW and Y$ROW matrices have been initial- 
ized, but before the matrix multiplication is 
performed. After the <CR> is typed, the program 
executes until the breakpoint is encountered. At 
this point, the monitor outputs a line specifying 
the number of the breakpoint, the CS and IP 
values and the first byte of the next instruction to 
be executed. 
.G 81B5- 55 962,AE 


BR1 @0100:00AE C7 . 


Next, the single-step capability is used with the 
*‘N’’? command to execute single instructions. At 
any time, CPU registers may be examined or 
changed. In this example, the ‘‘X’’ command is 
used. Execution of succeeding instructions is caused 
by typing a comma (,). 

.N @OAE- C7 , 

G0B4—- 81 , 

@O@BA- 7E , 

Q@OBF- C7 — 

+X 

AX=@018 BX=@@18 CX=FFFE DX=@009 SP=0@8D® BP=00D9 SI=H404 

DI=8@806 CS=0@188 DS=012A SS=@12A ES=0090 IP=60BF FL=F293 


-N @@BF- C7 , 
gocs- 81, 


QOCB- 7E 


The contents of the X$ROW and Y$ROW matrices 
are examined and changed with the ‘‘SW’’ (sub- 
stitute word) command. If a comma (,) is typed 
after the contents of memory are displayed, then 
the contents are left unchanged and the next word 
of memory is displayed. If a value followed by a 
comma or <CR=2 is entered, then the contents are 
changed. If a <CR> is entered, the substitute 
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sequence is terminated. 


.SW_DS:1A, @001-', 
OG1C OO01- , 

OG1E 8H01- 10 
.SW_DS:5A, FFFF- , 
O05C FFFE- , 

BO5E 2000- | 

0060 FFFF- 64 


After the matrices are modified, execution is 
resumed with the ‘‘G’’ command. The max value is 
output and the INT 3 instruction executed. Finally, 
the contents of the 3 matrices are displayed. 


-G @BCB- 7E 
MAX VALUE = +@9486 
@¥16@:81B5 55 
0016 O206 BBO 
6026 0601 8061 
0830 9603 8603 
0946 0884 8805 
0050 FFFE 80060 
00600 0864 FFFE 
2070 9600 6051 
680 FFE2 B08 


0612 
9003 
6064 
FFFE 
ey) 
GB800 
6129 


G0B1 
8062 
0084 
0805 
FFFF 
BYO0 
FFEC 
G1E8 


O001 
0602 
6004 
0088 
PFFE 
0888 
B20B 
FFCE 


6085 
FREE 
FREE 
6088 
FFD8 


Expanding the Example Program’s 
Memory Requirements 


To illustrate how the iSBC 86/12 board may be 
used for executing 8086 programs which require 
large amounts of RAM, the example program will 
be modified. The matrix dimensions of the example 
will be changed from values of 6, 5 and 3 for the 
literal symbols of M, N, and P to values of 100, 
50, 70. The three matrices will then be of size 
100X50, 50X70, and 100X70. The memory re- 
quired for these matrices is 15.5K words or 31K 
bytes. The data, constant, stack and memory 
segments which are contained in the group 
DGROUP will now comprise almost 32K bytes of 
memory. 


The extra memory requirements will be supplied 
by using an iSBC 032 board with the iSBC 86/12 
board in the iSBC 660 chassis. The iSBC 032 board 
is a 32K byte RAM board which is compatible 
with both 8- and 16-bit CPU boards. The base 
address of the board may be selected anywhere in 
a0 to 1 megabyte range on any 16K byte boundary. 
8- or 16-bit data transfers may be selected. The 
iSBC 032 board will be jumpered to respond to 
addresses in the 512K or 544K address space (20 
bit hex address range to 80000H to 87FFFH). This 
will illustrate the capabilities of the 8086 to access 
a 20-bit, 1 megabyte address range. 


One other modification is required to the program. 
The magnitude of the numbers which would result 
from multiplying matrices of this size would great- 
ly exceed the capacity of the 16-bit integer storage, 
even with the two matrices initialized to the small 
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values they presently contain. To keep the example 
simple, the initialization values will be changed so 
all elements of the X$ROW matrix are set equal to 
2 and all elements of the Y$ROW matrix are. set 
equal to 3. The result of the multiplication: should 
make all the elements of Z$ROW equal to 300.” 


The modified lines of program code are shown 
below. . 


"./* MATRIX DIMENSIONS: */ 


27. 1. DECLARE M LITERALLY '106';- 
28 1. ’’ DECLARE N' LITERALLY '56'; 
29 1 DECLARE P LITERALLY '70': 
36 1 DO I = @ TO (M-1); 

37 2 DO J = 6 TO (N-1); 

38 3 . AGROW (2) COL (J) = 2:° 
39 3 ’ BND; ; 

40 2 END; 

41 1 DO I = a TO (N- 1); 

42 2 po J i) TO (P-1); 

43 3 YSROW (I) .COL (3) = 3; 
44 3 END; 

45 2 END; 


The EXECUTION$VEHICLE module must be re- 
compiled and then the three. program modules must 
be linked and located using the QRL86 program. 

Specifying the SEGMENTS option of QRL86, the 
origin of the CODE segment which is in the group 
CGROUP is set at 1000H, as in the first example. 

However, the origin of the CONST, DATA 
STACK and MEMORY segments which make up 
the group DGROUP is set at 80000H. 


ORL86 :F1:MATRIX.OBJ,:F1:FIND.OBJ, | 
SBCIOS.LIB SEGMENTS (CODE(1000H), .- 
_ CONST (80000H), DATA STACK, MEMORY) 


The memory map generated by QRL86 shows the 

CGROUP having a start address of 01000H and 

the DGROUP ens a start address of 80000H. 
‘INVOKED ‘BY: 


QRL86 :F1l:MATRIY.OBJ,:F1:FIND. OBJ, /SBCIOS. LIB & : 
PE GNENTS (CODE (ORE) a CONST (800008) , DATA,STACK, /MEMORY ) 


INPUT “MODULES INCLUDED: 

- ¢Fls:MATRIY. OBJ (EXECUTIONVEHICLE) _ 
:F1:FIND.OBJ (FIND) 
SBCIOS. LIB (SBCCO): 


‘RESULT WRITTEN TO :F1:MATRIY (EXECUTIONVEHICLE) : 
START ADDRESS IS (61008, 0002H) 


| START LTH ALIGN NAME CLASS: > 


@1000H .298H G /GS/ CGROUP ~ | | 
“610604 21DH- W  CODE(EXECUTIONVEHICLE) CODE 


$121DH 41H -B. CODE(FIND). | CODE 
°  9125EH- 3AH W CODE (SBCCO) oe - CODE 
; /GE/ CGROUP 
8G68W0H 79768 G /GS/ DGROUP’ 3 
80000H CH Ww CONST (EXECUTIONVEHICLE) CONST 
 8000CH’ @H W  ..CONST(SBCCO) CONST 
8088CH 792AH Ww DATA (EXECUTIONVEHICLE) DATA 
-87936H (2H WwW DATA (FIND) DATA.” 
87938H OH Ww DATA(SBCCO) - DATA 
-87940H 30H SW STACK =... fe ' STACK 
87970H | ®@H W MEMORY ~— MEMORY, 7 
"=> + /GE/ DGROUP © ~ 
» 879768 OH G ??SEG (FIND) | ,  tethe (NULL) 


1-98 


- The object code is then converted to hex format 


and. downloaded to the iSBC 86/ 12 board. ‘When 
the program is. executed, the maximum. value As 
calculated and output, on the console. Oe 


28BC861 
' ISIS-11 ISBC: 86/12 LOADER, V1.2: * 5" 


ISBC 86/12 MONITOR,,V1.2 
.LS,:F1l:MATRIY. HEX 


-S1AC, F4- CC 
.G O662- FA 


MAX VALUE = +00300— 
@6100:G1AD 55 


VI. CONCLUSION 


This application note has Aaaived the iSBC 957 
Intellec—iSBC 86/12 . Interface and Execution 
Package, and how this package may be used to” 
develop and debug programs for the 8086 processor. 

First, the iSBC 86/12 single board. computer was 
described, followed. by a detailed description of the 
iSBC. 957 package and the. iSBC 86/12. system 
monitor commands. The power and versatility of 
the iSBC 957 package and monitor commands for 
developing. and debugging programs for the 8086 
were illustrated by a program example. In the 
example a program which consisted of PL/M-86 
and assembly language routines was presented. The 
program code was explained, and the steps required 
to compile, assemble, link, locate, and debug the 
program were illustrated. Finally, a typical de- 


bugging session using the iSBC 86/12 system moni- 


tor which illustrates the povet capabilities of the 
monitor was Pees oo 
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VLE6LO-NAV 


Y2 
15 MHZ 


BUS 
ARBITER 
ASSEMBLY 
J12 


5.0 MHZ CLK ed 
READY 


BUS ADE 


CLOCK 
GENERATOR 
A38 


STATUS 
DECODER 


LOCK - OVERRIDE 


P2 


ADV IO ADR 


AD16-AD19 


G 


COMMAND 
XACK/ . nen” DECODER 
ADO-AD15 16 A40/41/57 “ 


SLAVE MODE 


8 % 7 
DP ON BD ADR EN 
v DAD 
: Y T ADRO/-ADRB/. 
ADR10/-ADR13/ 16 ADRO/-ADR13/ 20 


ADDRESS 


1ST ACK 


ADO-AD7 


DUR 


cs 


ADDRESS 
BUFFER 
A42/58 


AB3-ABF 
ADRC/-ADRF/ 


vo 
ADDRESS 
DECODER 
A54/55/56 


10 AACK 


cs 
DATA 
BUS 
DRIVER 
A69/89 


LOCAL iNTA DEN 


DUAL PORT 
RAM 
(SEE FIG. 4-2) 


ENABLE 0 READ/WRITE 


LOCAL INTA DEN 


BUS INTA DEN 


READ/WRITE CONTROL 


RESET/ 


BUS INTA DEN 


RESET! 


Y1 
22.1184 MHZ 
it] 


cs RW cs RW DATA CS 9183.7 KHZ Eco cs INTR 
8255A PPI A25 8251A USART A27 - 8253 PIT A26 ro aeis incur 8259A PIC A24 a 


CLK 


TXC/RXC_ TXD CTR1 INTA 


INTERRUPT 
JUMPER 
: 2212 marae Eras 7 
0 51TX INTR o TMRO INTR MHZ  INTRE | 
° OVERRIDE INTRE/ 
. o 51RX INTR o TMA! INTR INTR7/ 
BIDIRECTIONAL Ic . 
ohnea SOCKETS TS 
PA | BUS |51TX | TMRO 
8 8 INTR | INTR | INTR | INTR 
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PB EXT 5SIRX TMRI1 
INTR INTRO INTR INTR 


iSBC™ 86/12 SIMPLIFIED LOGIC DIAGRAM 
INPUT /OUTPUT AND INTERRUPT 


(Z $0 L) V XIGN3ddV 


OOL-L 


VLE6LO-NSIV 


BUS ADEN. 


RAM XACK/ . 


XACK! 


Pt 
RESET; 


¥2 
= wt 
(SEE FIG. 4-1) ASSEMBLY 
ON BD ADR J12 


RESET) ~ 


_ b . : 
: 18.432 MHZ 
CLOCK ; 7 
GENERATOR. 5.0 MHZ CLK 
A38 
‘ READY STATUS 
DECODER 


SLAVE MODE 


40/41/57 


MULTIBUS 


AB10-AB13 
ADRO/-ADR13 


SLAVE MODE 
16 


ADO-ADF 


ADDRESS 


ADV vO ADR ABB-AB12 : BUFFER 
SEE FIG. 4-1 ; 
AB6 
PROM ENABLE en ae : 
PROM ENABLE : | 
G ~ puatront [oreo namcu> | | 
DECODER 
. A22/36/66/67 | 
PROM ENABLE : 
, p2 
ABI-ABC 12 A ” . » 4 ee 


A71/91 2 


MULTIBUS : 


ADO-ADF 16 


DATA BUS 
ORIVER 


DATS/DATF/ 
A90 . 


iSBC™ 86/12 SIMPLIFIED LOGIC DIAGRAM 
ROM/EPROM AND DUAL PORT RAM 


MEM -PROT/ Fl ; 


(2.40 Z) VW XIGNAddW 


APPENDIX B 
PROGRAM LISTINGS FOR EXECUTIONSVEHICLE AND FIND MODULES 
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PL/M-86 COMPILER EXECUTIONVEHICLE 


\ 


ISIS-II PL/M-86 V1.@ COMPILATION OF MODULE EXECUTIONVEHICLE 
OBJECT MODULE PLACED IN :F1:MATRIX.OBJ 


COMPILER INVOKED BY: PLM86 :F1:MATRIX.PLM DEBUG 


/* MATRIX MULTIPLICATION EXAMPLE PROGRAM 


PL/M-86 MAIN PROGRAM WHICH: 

A) INITIALIZES TWO INTEGER MATRICES 

B) MULTIPLIES THE TWO MATRICES AND STORES THE RESULT IN A 
THIRD MATRIX 

C) CALLS AN ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES THE 
THIRD MATRIX FOR THE MAXIMUM VALUE 

D) CALLS A PL/M PROCEDURE WHICH CONVERTS THE MAXIMUM VALUE 
FROM INTEGER TO ASCIT 

E) CALLS A PROCEDURE WHICH OUTPUTS THE ASCII CHARACTERS ON 
THE SYSTEM CONSOLE 


a 


EXECUTIONSVEHICLE: 
DO; a 


as, 


/* FINDSMX - EXTERNAL ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES A 
MATRIX FOR THE LARGEST ABSOLUTE MAGNITUDE. 
PARAMETERS: 
MATRIXSADR - ADDRESS OF THE MATRIX TO BE SEARCHED 
ROWS ~ NUMBER OF ROWS IN THE MATRIX 


COLS - NUMBER OF COLUMNS IN THE MATRIX 
* 


2 1] FINDSMX: PROCEDURE (MATRIXSPTR, ROWS, COLS) INTEGER EXTERNAL; 
a 2 DECLARE (ROWS, COLS) INTEGER; 
4 2 DECLARE MATRIXSPTR POINTER; 
5 2 END FINDSMX; 
/* BINSDECSASC - BINARY TO DECIMAL ASCII CONVERSION PROCEDURE 
PARAMETERS: ; 
VALUE - INTEGER VALUE TO BE CONVERTED TO ASCII 
CHARSARRAYSADR - ADDRESS OF 6 BYTE ARRAY WHERE ASCIT 
STRING CONTAINING THE VALUE WILL BE STORED 
*/ 
6 1 BINSDECSASC: PROCEDURE (VALUE, CHARSARRAYSADR) ; 
7 2 DECLARE (VALUE, TEMP, I) INTEGER; 
8 2 DECLARE CHARSARRAYSADR POINTER; 
9 2 DECLARE (CHARSARRAY BASED CHARSARRAYSADR) (6) BYTE; 
14 2 “IF VALUE < @ THEN 
]i 2 DO; 
12 3 CHARSARRAY(@) = '-'; /* SIGN CHARACTER */ 
13 3 TEMP = -VALUE; 
14 3 END; 
ELSE 
15 2 DO; 
160 3 CHARSARRAY(@) = '+'; 
17 3 TEMP = VALUE; 
18 3 END; 
19 2 DO T = 5 TO 1 BY -l1; 
28 3 CHARSARRAY (I) = UNSIGN(TEMP MOD 18) + 30H; 
2) 3 TEMP = TEMP/1@; 
/* ASCII CHARACTERS 24 THRU 39 HEX REPRESENT THE DIGITS @ THRU 9. THUS 
TO CONVERT AN’ INTEGER TO ASCII REPEATED DIVISIONS BY 16 AND ADDING 
THE REMAINDER TO 2@ HEX WILL ACCOMPLISH THE CONVERSION x/ 
22° 3 END; 
23 2 END BINSDECSASC; 
/* CO -— EXTERNAL PROCEDURE TO OUTPUT A CHARACTER TO THE SYSTEM CONSOLE. 
THIS PROCEDURE IS PART OF THE ISBC 957 LIBRARY FOR CONSOLE I/O 
PARAMETER: 
ry, CHAR - ASCII CHARACTER TO BE OUTPUT ON THE CONSOLE 
24 1 CO: PROCEDURE (CHAR) EXTERNAL; 
95 DECLARE CHAR BYTE; 
26 2 END CO; 
/* MATRIX DIMENSIONS */ 
27 ah DECLARE M LITERALLY '6'; 
28 l DECLARE N LITERALLY '5'; 
29 ] DECLARE P LITERALLY '3'; 
/* THE THREE MATRICES ARE DECLARED AS ARRAYS OF STRUCTURES. xSROW IS COMPOSED 
OF M STRUCTURES BACH OF WHICH IS COMPOSED OF N INTEGER ELEMENTS. THUS 
XSROW MAY BE THOUGHT OF AS A M X N MATRIX. THE MATRIX WILL BE STORED AS 
A ROW-ORDER MATRIX WITH THE ELEMENTS OF EACH ROW STORED IN ADJACENT MEMORY 
LOCATIONS. YSROW IS DECLARED AS AN X P MATRIX AND ZSROW AS A N X P MATRIX */ 
36 1 DECLARE XSROW(M) STRUCTURE (COL(N) INTEGER); 
31 ol DECLARE YSROW(N) STRUCTURE (COL(P) INTEGER); 
321 DECLARE Z$ROW(M) STRUCTURE (COL(P) INTEGER) ; 
33. 2 DECLARE (1,7,K,MAX) INTEGER; 
aa DECLARE MAXSASCSARRAY (6) BYTE; 
35° DECLARE TEXT (*) BYTE DATA ('MAX VALUE = '); 
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ao 


©©) 


ae 


/* INITIALIZE X$ROW SUCH THAT THE FIRST ROW IS SET EQUAL TO 6, THE SECOND 
ROW EQUAL TO 1, THE THIRD ROW EQUAL TO 2, ETC. */ 


] DO I = @ TO (M-1); 
2 DO J = @ TO (N-1);. 
3 XSROW(I).COL(J) = Tj; 
3 END; 
2 END; 
/* INITIALIZE YSROW SUCH THAT THE FIRST COLUMN IS SET EQUAL TO @, THE 
SECOND COLUMN EQUAL TO -1, AND THE THIRD COLUMN EQUAL TO ~2. */ 
1 DO I = @ TO (N-1); 
2 DO J = @ TO (P-1); 
3 YSROW(I).COL(J) = -J; 
3 END; 
2 END; 
/* PERFORM MATRIX MULTIPLICATION */ 
) DO K = @ TO (P-1); 
2 DO I = 6 TO (M-1); 
3 ZSROW(I).COL(K) = @; /* SET ZSROW ELEMENT TO @ */ 
3 DO J = @ TO (N-1); /* SUM THE PRODUCT OF XSROW ROW TERMS AND YS$ROW COLUMN TERMS */ 
4 ZSROW(I).COL(K) = ZSROW(I).COL(K) + ( XSROW(I).COL(J) * YSROW(J).COL(K) 
4 END; 
3 END; 
2 END; 
1 MAX = FINDSMX (@ZSROW, M, P); /* FIND MAX VALUE OF ZSROW */ 
] CALL BINSDECSASC (MAX, @MAXSASCSARRAY); /* CONVERT TO DECIMAL ASCII */ 
1 DO I = # TO (SIGNED(SIZE(TEXT)) - 1); /* OUTPUT HEADER TEXT */ 
2 CALL CO(TEXT(I)); 
2 END; 
} DO I = @€ TO 5; /* OUTPUT ASCII MAX VALUE */ 
2 CALL CO(MAXSASCSARRAY(I)); 
2 END; 
1 END EXECUTIONSVEHICLE; 


MODULE INFORMATION: 


CODE AREA SIZE = @225H 549D 
CONSTANT AREA SIZE = @# CCH 12D 
VARIABLE AREA SIZE = #@9RH 144D 
MAXIMUM STACK SIZE = @®/8H 8D 


137 LINES READ 
@ PROGRAM FRROR(S) 


END OF PL/M-86 COMPILATION 


ISIS-II MCS-86 ASSEMBLER ASSEMBLY OF MODULE FIND 
OBJECT MODULE PLACED IN :F1:FIND.OBJ 
ASSEMBLER INVOKED BY: ASM86 :F1:FIND.ASM DEBUG 


LOC OBJ 


LINE SOURCE 


1 NAME FIND 

2 PUBLIC FINDMX 

3 ; 

4 ; 

5 i 

6 ; FINDMX 

7 ; ASSEMBLY LANGUAGE PROCEDURE TO FIND THE ELEMENT OF AN INTEGER 

8 ; MATRIX WITH THE LARGEST ABSOLUTE MAGNITUDE, THE VALUE OF THE 

9 ; ELEMENT IS RETURNED IN THE AX REGISTER. 

18 ; 
1l ; PL/M CALLING SEQUENCE: 

12 ; MAXSVALUE = FINDSMX(ADRSOFSMATRIX, #SOFSROWS, #SOFSCOLS) ; 
13 ; 

14 ; PARAMETERS: 

15 ; ADRSOFSMATRIX — ADDRESS OF THE MATRIX WHICH WILL BE SEARCHED 
16 ; #SOFSROWS - NUMBER OF ROWS IN THE MATRIX 

17 7 #SOFSCOLS - NUMBER OF COLUMNS IN THE MATRIX 

18 ; 

19 : PL/M WILL PASS THE THREE PARAMETERS IN THE CALL TO THIS PROCEDURE ON 
20 ; THE STACK. ON ENTRY TO THE PROCEDURE SP+6 WILL POINT TO THE FIRST © 
21 ; PARAMETER (ADRSOFSMATRIX) AND SP+4 AND SP+2 WILL POINT TO THE SECOND 
22 ; AND THIRD PARAMETERS. 

23 ; 

24 ; THE PROCEDURE IS A TYPED PROCEDURE WHICH ASSIGNS THE MAXIMUM VALUE 
25 ; IN THE MATRIX TO A VARIABLE (IN THIS,.CASE MAXSVALUE) IN A PL/M 

26 ; ASSIGNMENT STATEMENT. TO ACCOMPLISH THIS ASSIGNMENT THE VALUE IS 

27 ; RETURNED IN THE AX REGISTER. 

28 ; 

29 7 

30 : THE ALGORITHM USED IS SIMILAR TO THE FOLLOWING PL/M CODE: 

31 : FOR I = @ TO (#SOFSROWS - 1); 

32 ; FOR J = @ TO (#S$OFSCOLS - 1); 

33 ; IF IABS(MATRIX(I).Y(J)) > IABS(MAX) THEN MAX = MATRIX(I).Y¥(J); 
34 : END; . 7 — 
35 : END; 

36 ; 

37 ; WHERE IABS (XYZ) REPRESENTS THE ABSOLUTE VALUE OF THE INTEGER XYZ 
38 ; 

39 ; 
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© 


© 


® 


LOC OBJ 


OHOGD 


BABS 


BB 
OO 
BAG 


OFBE 
#2OB 
HA01 
08A3 
Q205 
0287 
8889 
8BHD 
OB1B 


6A12 


HOLS 
6817 
AB19 
281B 
6@1D 
AQ1F 
e821) 
GA23 
“C25 
0828 
6A2B 
A82D 
OO2F 
€G31 
7934 
¢835 
0038 
603A 
83D 
8@3E 


-——— = 


BAAD 


6[] 
4t] 
8] 


55 

8BEC 
33D2 
8BFA 
8BF2 


89160000 
8B4EH4 


DIE] 


&BSEA8 


8B8O 
OBCO 
7962 
F7D8 
3BC2 
7007 
8BDF 
BBE 


A38628 
83C602 


3BF1 
72E6 
8D18 


BE@OOB 


47 


3B7E86 


72DB 


A16G898 


5D 


C2A68B 


SYMBOL TABLE LISTING 


ee ee ee eee 


NAME 

??SEG .. 
ABC... ; 
ADR OF MATRIX 
CGROUP. . 
CODE. .. 
DATA. .. 
DEF... 
DGROUP. . 
FINDMX. . 
MAX... 


NO OF COLS. 


NO_OF_ROWS, . 


STACK .. 
XYZ... 


TYPE 


SEGMENT 
L NEAR 
V WORD 

GROUP 

SEGMENT 
SEGMENT 
L NEAR 
GROUP 

L NEAR 
V WORD 
V WORD 

V WORD 
SEGMENT 
L NEAR 


VALUE 


@815H 
G@88H 


@81DH 


CEOGH 
2OOOH 
O004H 
26@6H 


0%28H 


SOURCE | 

i . i 

; DEFINE GROUPS TO CONFORM WITH PL/M-86 CONVENTIONS. DATA, STACK, AND 

; CODE SEGMENTS WILL BE APPENDED TO THEIR RESPECTIVE SEGMENTS IN THE 

: PL/M-86 MODULES. ah 

DGROUP GROUP DATA,STACK 

CGROUP GROUP CODE 

; . | ees 

+ INSTRUCT THE ASSEMBLER THAT THE DS, SS, AND CS REGISTERS WILL CONTAIN 
; THE BASE ADDRESS VALUES FOR THE DGROUP, DGROUP AND CGROUP GROUPS. 


ASSUME DS:DGROUP,SS:DGROUP,CS:CGROUP 


DATA SEGMENT WORD PUBLIC ‘DATA’ 
MAX DW 6 . 
‘ENDS 


DATA 


t i 
pea aKKRRKERAEKERESTACK SEGMENT 


STACK SEGMENT STACK ‘STACK’ 
DW 14 DUP (@) 
STACK ENDS. 


pA aR OR Rw ER RCODE SEGMENT 


; 
CODE 


;RESERVE 13 WORDS OF STACK FOR MONITOR 


;AND 1 WORD FOR FINDMX PROCEDURE 


;PARAMETERS ON STACK, DISPLACEMENT FROM TOS INCREASED BY TWO DUE TO INITIAL PUSH 


SIZE=8041H BYTE PUBLIC 'CODE' 
SIZE=@862H WORD PUBLIC '‘'DATA' 
CODE 


. DATA STACK 


CODE PUBLIC 
DATA 
[BP] 
[BP] 
SIZE=661CH 
CODE 


PARA STACK 'STACK! 


ASSEMBLY COMPLETE, NO ERRORS FOUND 
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; PROCEDURE DECLARATION 


;BP POINTS TO PARAMETERS ON STACK 


ABS OF CURRENT MAX = @ 
I (ROW INDEX) = @ 

J(COLUMN INDEX) = 8 
CURRENT MAX = @ 


(#SOFSCOLS) * 2 


FOR J(SI) INDEX 


;ADRSOFSMATRIX PARAMETER 
;BX POINTS TO FIRST ELEMENT OF A GIVEN ROW 


OF MATRIX 
= Q 


;NEGATE TO FORM POSITIVE NUMBE 


;COMPARE TO CURRENT MAX 
;JUMP IF LESS THAN CURRENT MAX 


BX + (2 * #SOFSCOLS), 


OF CURRENT MAX 
VALUE TO CURRENT MAX 


INDEX BY TWO 
ROW ?? 
BACK FOR NEXT ELEMENT OF THIS ROW 


DO THE NEXT ROW 


;RETURN MAX VALUE IN AX REGISTER 
;RESTORE BP REGISTER 
; INCREMENT SP BY 6 AND RETURN TO CALLER 


SEGMENT BYTE PUBLIC 'CODE' 
NO OF ROWS . EQU WORD PTR [BP+6} 
NO OF COLS EQU WORD PTR [BP+4] 
ADR_OF MATRIX  EQU WORD PTR [BP+8] 
FINDMX PROC NEAR 
PUSH BP ;SAVE BP REGISTER 
MOV BP,SP 
XOR DX,DX ;SET DX = 
MOV DI,DX ;DI = 
MOV SI,DX 7SI = 
MOV MAX ,DX ;MAX = 
MOV CX,NO_OF_COLS 
SHL CX,1 7CX = 
; TERMINATION 
MOV BX,ADR_OF MATRIX 
ABC: MOV AX, [BX] [ST] ;GET ELEMENT 
OR AX,AX +SET FLAGS 
JNS © DEF ;JUMP IF SIGN 
NEG AX 
DEF: CMP AX,DX 
JL XYZ 
MOV DX, AX ;MOVE TO ABS 
MOV AX, [BX] [ST] ;MOVE MATRIX 
MOV MAX, AX 
XYZ: ADD SI,2 ; INCREMENT J 
CMP SI,CX ;END OF THIS 
JB ABC _71F NO, LOOP 
LEA BX, [BX+STI] ;BX = 
MOV SI,@ 7J = 6 
INC DI ;I =I 41 
CMP DI,NO OF ROWS ;LAST ROW ?? 
JB ABC ;IF NO, 
MOV -AX,MAX 
POP BP 
RET 6 
, 
FINDMX ENDP . 
’ 
CODE ENDS 
‘ 
END 
ATTRIBUTES 
SIZE=@@0@H PARA PUBLIC 
CODE 
{BP} 
CODE 
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BX POINTS TO NEXT ROW 


ISIS-II ORL-€4, 


INVOKED BY: 


QORL85 :FJ:MATRIX.OBJ,:F]:FIND.OBJ,SBCIOS.LIB ORIGIN(1@@FH) 


Vi.1 


INPUT MODULES INCLUDED: 
:F1:MATRIX.OBJ (RXFCUTTONVENICLE) 


:P1:FIND.OBJ (FIND) 


SBCIOS.LIB(SBCCO) 


RESULT WRITTEN TO 


START ADDRESS IS 


START LTA 
A1GGAH 2A7H 
AIOAOH 225H 
8]225H 418 
A1266H 3AH 


O12A¢H D@H 


@12A@H CH 
P12ACH OH 
@12ACH 9@H 
@133CH 2H 
G133EH BH 
@1340H 39H 
81376H OH 
¢ 376H AH 


DEBUG MAP OF 


-@12AH,@@DOH 
G#1ACH, #1B5H 
#12AH, A@GCH 
A] 2AH, OB PEH 
#).2AH,@010H 
@12AH,A%@4CH 
@12AH, CAGAH 
812AH,898EH 
O®12AH,A890H 
6) 2AH, 009 2H 
@12AH,¢9094H 
4] 2AH,@A96H 
A12AH, (OOOH 
G100H,fIB5H 
¥190H,@1B8H 
AIGP7H,B1C 2H 
A1O?H,A1C8H 
B1ACH, @1IDIH 
@1698H,f1D4H 
#100H,#@1DAH 


2 FJ] :MATRIX (EXECUTTONVEHICLE) 


(01@0H, 70028) 


ALIGN NAME 


=vsao 


:n 
ZEEE TLzO 


Q 


/GS/ CGROUP 


CODE (EXECUTIONVEHTCLE} 


CODE (FIND) 

CODE (SBCCQ) 
/GE/ CGROUP 
/GS/ DGROUP 


CONST (EXECUTIONVEHICLE) CONST 
CONST (SRCCO) 


DATA (EXECUTIONVEHICLE) 


DATA (FIND) 
DATA (SBCCO) 
STACK 
MEMORY 
/GE/ DGROUP 
??SEG (FIND) 


CLASS 


CODE 
CODE 
CODE 


CONST 
DATA 


DATA 
DATA 


STACK 
MEMORY 


(NULL) 


:F1l:MATRIX (EXECUTIONVEHICLE) 


MODULE: 
SYMBOL: 
SYMBOL: 
SYMBOL: 


SYMBOL: 
SYMBOL: 


SYMBOL: 


SYMBCL: 


SYMBOL: 
SYMBOL: 
SYMBOL: 
SYMBOL: 
SYMBCL: 
SYMBOL 


LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 


EXECUTTONVEHICLE 


MEMORY 
BINDECASC 
TEMP 

I 

XROW 

YROW 

ZROW 

A 

J 

K 

MAX 
MAXASCARRAY 
TEXT 


1¢@ 
12 
13 
14 
16 
17 


O100H,O1E1H 
G10CH, C1FBH 
100H,0213H 
C100H,f21EH 
010GH,8221H 
G12OH, AEO2H 
@100H,@@21H 
P100H, 203 2H 
#10CH,004BH 
C1AOH, 09544 
A 100H, GO5DH 
CIGPH, PO6EH 
C100H,007FH 
7100H, O09CH 
@100H,@0A5H 
0100H,@QAEH 
(100H,O@BFH 
0100H, BODCH 
(10H, MOE7H 
1100H, 0OF8H 
#100H,8130H 
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LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 


SMe ste He te EEO SE SE HE OE SR OSE OSE SHE SEH HE SE EH 
on ee se 2 06 ee 80 oe te ee te 


ee te 


19 
26 
21 
22 
23 
36 
37 
38 
R9 
49 
4] 
42 
43 
44 
45 
46 
47 
48 
49 
5@ 
51 


@1@¢H,@13¢CH 
®8106H,F142H 
@109GH,@14BH 
H160H,€15EH 
M1G8GH,P169H 
G1€6H,@17AH 
f19@H,B185H 
G810@H,318EH 
9100H,?) OFH 
019¢H,71AAH 
G190H,%1B3H 


61090H,@23AH 
8190H,€242H 
0186H,9225H 
@12AH,@8@9CH 
G126H,@24DH 
$1¢G0H,8225H 


€100H,8266H 


LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
LINE 
MODULE: 
SYMBOL: 
SYMBOL: 
SYMBOL: 
SYMBOL: 
SYMBOL: 
PUBLIC: 
MODULE: 
PUBLIC: 


ste tte ose hb OH HR SE EO SE tHE OE 
os 00 oe 08 ee 68 oe 88 oe 8 


. 
. 


52 
53 
54 
55 
56 
57 
58 
oo 
60 
61 

62 

FIN 
ABC 
DEF 
FINDMX 
MAX 
XYZ 
FINDMX 
SBCCO 
CO 


AFN-01931A 


PROGRAM LISTING FOR EXECUTIONSVEHICLE MODULE WITH CODE EXPANSION 


PL/M-86 COMPILER 


APPENDIX C 


EXECUTIONVEHICLE 


ISIS-II PL/M-&86 V1.@ COMPILATION OF MODULE EXECUTIONVEHICLE 
NO OBJECT MODULE REQUESTED 


COMPILER INVOKED BY: PLM&86 :F]:MATRIX.PLM DEBUG CODE NOOBJECT PRINT(:F1:MATRIX.XLS) 


A O&'y dH 


& Oo OrI 


wes 
Nore 


13 


14 


ww 
oy 


17 


18 
19 


NNN Y 


NO NM 


Wh 


iw 


/* MATRIX MULTIPLICATION EXAMPLE PROGRAM 


PL/M-86 MAIN PROGRAM WHICH: 
A) INITIALIZES TWO INTEGER MATRICES 


B) MULTIPLIES THE TWO 


THIRD MATRIX 


C) CALLS AN ASSEMBLY LANGUAGE PROCEDURE WHICH SEARCHES THE 


THIRD MATRIX FOR THE MAXIMUM VALUE 


D) CALLS A PL/M PROCEDURE WHICH CONVERTS THE MAXIMUM VALUE 


FROM INTEGER TO ASCII 


E) CALLS A PROCEDURE WHICH OUTPUTS THE ASCII CHARACTERS ON 


THE SYSTEM CONSOLE 


*/ 


EXECUTIONSVEHICLE: 
DO; 


/* FINDSMX - EXTERNAL ASSEMBLY LANCUAGE PROCEDURE WHICH SEARCHES A 


MATRIX FOR THE LARGEST ABSOLUTE MAGNITUDE. 


PARAMETERS: 
MATRIXSADR 


ADDRESS OF THE MATRIX TO BE 


ROWS - NUMBER OF ROWS IN THE MATRIX 
COLS - NUMBER OF COLUMNS IN THE MATRIX 


wi 


MATRICES AND STORES THE RESULT IN A 


SEARCHED 


FINDSMX: PROCEDURE (MATRIXSPTR, ROWS, COLS) INTEGER EXTERNAL; 
DECLARE (ROWS, COLS) INTEGER; 
DECLARE MATRIXSPTR POINTER; 


END FINDSMX; 


/* BINSDECSASC ~ BINARY TO DECIMAL ASCII CONVERSION PROCEDURE 


PARAMETERS: 


VALUE - INTEGER VALUE TO BE CONVERTED TO ASCII 


CHARSARRAYSADR - ADDRESS OF 6 BYTE ARRAY WHERE ASCII 


STRING CONTAINING THE VALUE WILL BE STORED 


wea 
BINSDECSASC: PROCEDURE 
BINDECASC 
G1B5 55 PUSH 
®1B6 &BEC MOV 


DECLARE (VALUE, TEMP, I) 


(VALUE, CHARSARRAYSADR) ; 


; STATEMENT # 5 
PROC NEAR 
BP 
BP,SP 


INTEGER; 


DECLARE CHARSARRAYSADR POINTER; 
DECLARE (CHARSARRAY BASED CHARSARRAYSADR) (6) BYTE; 


IF VALUE < @ THEN 


G1BR BI1T7EMADABA CMP 
fIBD 7C@3 JL 
B1BF E91]29@ JMP 
DO; 
CHARSARRAY(@) = '-'; 
B1lC2 B8B5ER4 MOV 
@1C5 C6872D MOV 
TEMP = -VALUE; 
G1C8 8B46R6 MOV 
G1CB F7D8 NEG 
FICD 89fhERDLD MOV 
END; 
@1D1 EXSDGA JMP 
@l: 
ELSE 
DO; 
CHARSARRAY(@) = '+!'; 
@1D4 8BS5E@4 MOV 
Q1D7 CG6@72B MOV 
TEMP = VALUE; 
(]DA 8B4606 MOV 
Z1DD 89AGPP BR MOV 
END; 
@2: 


DO I = 5 TO 1 BY -1; 


PIE] C7A6A292 0508 MOV 

@1E7 E688 IMP 
@3: 

BIEA S810602C0F FFF ADD 


; STATEMENT #4 124 
[BP]. VALUE, @H 
$+5H 
@l 


/* SIGN CHARACTER */° 
; STATEMENT # 12 
BX, !BP] . CHARARRAYADR 
CHARARRAY [BX] , 2DH 


+ STATEMENT # 13 
AX, [BP]. VALUE 
AX , 
TEMP,AX 


; STATEMENT # 14 
@2 


; STATEMENT # 16 


BX, [BP] .CHARARRAYADR 
CHARARRAY / BX], 2BH 


; STATEMENT #.17 


AX, [BP]. VALUE 
TEMP ,AX 


; STATEMENT # 19 
I, 5H 
@5 


1, OFFFFH 
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20 


21 


22 


23 


24 
25 
26 


27 
28 
29 


Nore 


be 


@5: 


PIFE B813EA2EEA1EDH CMP I,1H 
@1F6 7D@3 : JGE $+5H 
Q1F8 E926¢¢ ; JMP @4 


CHARSARRAY (I) = UNSIGN(TEMP MOD 18) + 3@H; 


; STATEMENT # 26 


@1FB 8Be62000 MOV AX, TEMP 

O1FF BOBAGE MOV CX, OAH 

@282 31D2 XOR DX,DX 

204 FT7F9 IDIV Cx 

9206 81023800 ADD DX, 30H 

G20A 8B5ER4 MOV BX, [BP]. CHARARRAYADR 
28D 8B360209 MOV ST, 

9231 s88le MOV 'BX]. CHARARRAY [SI] ,DL 


TEMP = TEMP/19; 


3 STATEMENT # 21 


/* ASCII CHARACTERS 38 THRU 39 HEX REPRESENT THE DIGITS # THRU 9. 
TO CONVERT AN INTEGER TO ASCII REPEATED DIVISIONS BY 1@ AND ADDING 
THE REMAINDER TO 3@ HEX WILL ACCOMPLISH THE CONVERSION */ 


(213 8BA6HER MOV AX, TEMP 
@217 99 CWD 7 
0218 F7F9 _ IDIV CX. o 
O21A 89868008 MOV ~ TEMP ,AX 
END; | ae 
; STATEMENT # 22 
@21E ESCOFF JMP @3 - 
@4: 
END BINSDECSASC; 
; STATEMENT # 23 
6221 5D POP BP 
(222 c2n4ne RET 4H 
BINDECASC ENDP 


THUS 


/* CO ~— EXTERNAL PROCEDURE TO OUTPUT A CHARACTER TO THE SYSTEM CONSOLE. 


THIS PROCEDURE IS PART OF THE ISBC 957 LIBRARY FOR CONSOLE I/0 


PARAMETER: 


* 


CO: PROCEDURE (CHAR) EXTERNAL; 


DECLARE CHAR BYTE; 
END CO; 


/* MATRIX DIMENSIONS * 
DECLARE M LITERALLY '6'; 
DECLARE N LITERALLY '5!; 
DECLARE P LITERALLY '3'; 


/ 


CHAR - ASCII CHARACTER TO BE OUTPUT ON THE CONSOLE 


/* THE THREE MATRICES ARE DECLARED AS ARRAYS OF STRUCTURES. X$ROW IS COMPOSED 
OF M STRUCTURES EACH OF WHICH IS COMPOSED OF N INTEGER ELEMENTS. THUS 
XSROW MAY BE THOUGHT OF AS A M X N MATRIX. THE MATRIX WILL BE STORED AS 
A ROW-ORDER MATRIX WITH THE ELEMENTS OF EACH ROW STORED IN ADJACENT MEMORY 
LOCATIONS. YSROW IS DECLARED AS A N X P MATRIX AND Z$ROW AS A N X P MATRIX */ 


3 
3) 
22 


323 
34 
35 


346 


37 


38 


39 


DECLARE XSROW(M) STRUCTURE (COL(N) INTEGER) ; 


DECLARE YSROW(N) STRUCTURE 


(COL ( 


P) INTEGER); 


DECLARE ZSROW(M) STRUCTURE (COL(P) INTEGER); 


DECLARE (1,J,K,MAX) INTEGE 


Ri 


DECLARE MAXSASCSARRAY (6) BYTE; 


DECLARE TEXT(*) BYTE DATA 


/* INITIALIZE XSROW SUCH THAT THE FIRST ROW IS SET EQUAL TO @, THE SECOND 


("MAX 


VALUE = '); 


ROW EQUAL TO 1, THE THIRD ROW EQUAL TO 2, ETC. */ 


DO I = @ TO (M-)); 


; STATEMENT # 36 


OAG2 FA CLI 
OO83 2ESE16AAEE MOV ' $S,CS:@@STACKSFRAME 
O028 BCA8AD MOV SP,@@STACKSOFFSET 
020B 8BEC MOV BP,SP 
GOGD 16 PUSH ss 
OOGE IF POP DS 
A00F FB STI 
G618 C7H68290F900 MOV 1, 7H 
@6: 
A016 813E820005BR CMP 1,5H 
G01C T7E@3 JLE $+5H 
PO1E E93CRH IMP @7 
DO J = @ TO (N-1); 
; STATEMENT # 37 
0721 C7B6842000Re MOV J,0H 
C8: 
0727 813E84909490 ~ CMP J,4H 
Q02D 7ER3 JLE $+5H 
OO2F E9220¢ IMP e9 
XSROW(I).COL(J) = I; 
3; STATEMENT # 38 
OO32 8BAE682e0 MOV AX,I 
A836 BOCARE MOV CX, (AH 
0739 FT7E9 IMUL Cx 
643B 8B36849n7 MOV SI,J 
@03F DI1E6 SHL SI,1 
0641 89C3 MOV BX,AX 
9043 &BAE8208 MOV CK ,I 
GH47 898se4ae MOV [BX].XROWISI],CX 


END; 
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46 


4) 


42 


43 


4a 


45 


46 


‘8 


49 


we) 


WW 


CF AAB 
G35] 


EN 


G05 4 
RASA 


/* 
DO 
#@85D 


O63 
BEY 
BEG6B 


OM6E 


8074 
OHTA 
B27C 


OO7F 
0883 
A885 
8886 
BORA 
®A8D 
O@8F 
8893 
2895 
8¢97 
AAYIB 


AAC 
OAA2 


EN 


AGAS 
AKAB 


/* 
DO 


CRAE 


PHBA 
ACBA 
OABC 


ACBF 


FACS 


CECB 
ABCD 


HADES 
@OD4 
AAD7 
ABDI 
PADD 
AODE 
@GE1 


OAE7 


AGED 
OOF 3 
OWES 


ACES 
OP ABEC 
OGFF 
6191 
O15 
A187 
G18 
B1AC 
B1OF 
6111 
#115 
Al17 
8119 
@11D 
G11E 
G122 
$123 
#127 
0129 


; STATEMENT # 39 


PIA*6B4APA1GE ADD J,1H 
EOD3FF JMP C8 

@°; 

D; 
; STATEMENT #4 486 

B1PHLE2GGB1 EH ADD I,JH 
EOBOFF JMP C6 

@7: 


INITIALIZE YSROW SUCH THAT THE FIRST COLUMN IS SET EQUAL TO @, THE 
SECOND COLUMN EQUAL TO —1], AND THE THIRD COLUMN EQUAL TO -2. */ 


I = @ TO (N-1); 
; STATEMENT # 41 
C7GG82AFHALA MOV 1,08 
@lA: 
BSIBEB2BAB4AR CMP I,4H 
7E@3 JLE S+5H 
E94808 ‘IMP @]] 
DO J = @ TO (P-1); 
; STATEMENT # 42 
C7THA684G00N E40 MOV J,@H 
@l12: 
B13ZE848GH209 CMP J,2H 
TEG3 JLE $+5H 
E9262 JMP @13 
YSROW(I).COL(J) = -d; 
3; STATEMENT # 43 
RBL68 480 MOV AX,J 
F7D8 NEG . AX 
58 PUSH AX | 
8B468208 MOV AX,I 
BIB68OH MOV CX, 6H 
F7E9 IMUL CX 
8B368480 MOV SI,J 
DIE6 SHL SI,1 
89C3 MOV BX,AX 
59 POP CX ee 
89884008 MOV [BX]. YROW{[SI],CX 
END; 
3; STATEMENT # 44 
81G684AHL1A¢ ADD J,1H 
EQ9CFFF JMP e€12 
@13: 
D; 
; STATEMENT # 45 
BIAGB2GBG14F ADD I,1H 
EOSB5FF JMP C14 
@ll: 


PERFORM MATRIX MULTIPLICATION */ 
K = @ TO (P-1); 
; STATEMENT # 45 


CTARBSABAEBL MOV K,@H 
@14; 

LIZBERSARA2ZDG CMP K,2H 

TEAS JLE $+5H 

E98CHraA IMP @15 


DO I = @ TO (M-1); 
; STATEMENT # 47 


CTRER2ECHALL MOV 1,?H 
C16: 

BIZE820RE5EGF CMP I, 5H 

7E#B3 JLE S+5H 

EO&72¢¢ JIMP ajy7 


ZSROW(I).COL(K) = @; /* SET ZSROW ELEMENT TO @ */ 
; STATEMENT #§ 48 


BL 6820 MOV AX, I 

BOMGRE MOV CX, SH 

F7E9 IMUL CX 

8B 368608 MOV SI,K 

DIES SHL St 

89C3 MOV BX,AX 

C7TBPS5EDAN BAS MOV [BX].ZROWISI],(CH 


DO J = @ TO (N-1); /* SUM THE PRODUCT OF XSROW ROW TERMS AND YSROW COLUMN TERMS */ 
3; STATEMENT # 49 


CTCh6SAAABAGH MOV J,@H 
@18: 

8132E8402040G CMP 3,48 

7E@3 JLE $+5H 

E941 @9 IMP @19 


ZSROW(I).COL(K) = ZSROW(I).COL(K) + ( XSROW(I).COL(J) * YSROW(J).COL(K) ); 
3; STATEMENT # 54 


8B 068202 MOV AX,I 

BORAGE MOV CX, AH 

F7E9 IMUL cx 

8B3684f0 MOV sive 

DIE6 SHL a ie 

58 PUSH AX 1 
SB268400 MOV Ago 

BOO6BE MOV CX, 6H 

F7E9 IMUL cx 

8B3E8600 MOV DI,K 

D1E7 SHL DI,1 

89C 3 MOV BX, AX 

8B814 206 MOV AX, [BX]. YROW!DI] 


5B POP Xx es 
F7A8A 488 IMUL [BX]. XROW[ST] 
58 PUSH AX ae 
8BB682AB MOV AX,I 

F7E9 IMUL CX 

89C3 MOV BX,AX 
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F12B 58 AX e 2 
#12C G1815ER6 ADD 'BX].ZROW[DI],AX 
51 4 END; 
; STATEMENT # 51 
8130 810684908199 ADD J,1H 
4135 E9QB4FF JMP @18 
@19: 
52. 3 END; 
; STATEMENT # 52 
#139 810582000108 ADD 1,14 
@13F E983FF IMP @16 
@17: 
53 2 END; 
; STATEMENT # 53 
M142 818686090100 ADD K,1H 
4148 BOSOFF JMP a4 
@JS: 
54 ] MAX = FINDSMX (@ZSROW, M, P); /* FIND MAX VALUE OF ZSROW */ 
; STATEMENT # 54 
#14B B85EGA MOV AX,OFFSET (ZROW) - 
GF1I4E 5A PUSH AX 7 1 
Q14F BEREAY MOV AX, 6H 
7152 54 PUSH AX ; 2 
@153 Bar3eR MOV AX, 3H 
M156 54 PUSH AX 7 3 
4157 Eseeae ‘CALL FINDMX 
Q15A 89968808 MOV MAX, AX 
55 1 CALL BINSDECSASC (MAX, @MAXSASCSARRAY); /*. CONVERT TO DECIMAL ASCII */ 
3; STATEMENT # 55 
O15E FF3268898 PUSH MAX od 
8162 B&8AKB MOV AX, OFFSET (MAXASCARRAY ) 
@165 5¢ PUSH AX : 2 
0166 E84COR CALL BINDECASC 
56 1 DO I = @ TO (SIGNED(SIZE(TEXT)) - 1); /* OUTPUT HEADER TEXT */ 
; STATEMENT # 56 
8169 C78682nG00RK0 MOV I, 6H 
@20: 
@16F @13E820e¢eBa0 CMP 1,@BH 
8175 7EA3 JLE $+5H 
6177 §£914A9 JMP @21 
57 2 CALL CO(TEXT(I)); 
; STATEMENT # 57 
f17A &B1E8286 MOV BX,I 
G617E FFB76A90 PUSH TEXTIBX]; 1 
7182 E8RGR8 CALL co 
58 2 END; 
; STATEMENT # 58 
G185 81N6820nG190 ADD I,1H 
918B ESEI1FF JMP C28 
@21: 
59 1 DO I = @ TO 5; /* OUTPUT ASCII MAX VALUE */ 
; STATEMENT # 59 
P18E C7e682eng0n98 MOV I,@H 
@22; 
0194 813E820n05R8 CMP T,5H 
619A 7ER3 JLE $+5H 
f19C B91490 JMP @23 
64 2 ' CALL CO(MAXSASCSARRAY(T)); 
; STATEMENT # 60 
Q19F S8BI1ER2H¢ MOV BX,I 
@1A3 FFB78A89 PUSH MAXASCARRAY [BX]; 1 
G1A7 E8QH80 CALL (ore) 
Al 2 END; 
; STATEMENT # 61 
GJAA 810682980102 ADN I,1H 
#1B@ EOELFF JMP @22 
@23: 
62 1 END EXECUTIONSVEHICLE; 
: STATEMENT # 62 
0@1B3 FB STI a 
@1B4 F4 HLT 
MODULE INFORMATION: 
CODE AREA SIZE = §225H 549D 
CONSTANT AREA SIZE = @f#@CH 12D 
VARIABLE AREA SIZE = @6906H 144D 
MAXIMUM STACK SIZE = 6@@8H 8D 


137 LINES READ 
fi PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 


POP 
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I. INTRODUCTION 


As the microcomputer system found its way into 
more and more demanding applications the need 
became clear for a new and innovative solution to 
the old problem of providing timely response to 
real world events. This need was never clearer 
than in the field of communications where 
throughput and response time are the keys to 
success. The iSBC 544 Intelligent Communica- 
tions Controller (ICC) is the vanguard of a family 
of intelligent slave computers that provide a 
unique and powerful answer to the needs of the 
microcomputer user. 


This application note is intended to introduce the 
reader to the intelligent slave concept in general 
and the iSBC 544 board in particular. After a 
brief overview of the evolution of the concept and 
the features it provides, the hardware and 
software aspects of the controller are studied. 
Following this a summary of various system 
throughput tests is examined to evaluate the 
performance of the intelligent slave versus more 
traditional system architectures. We then study 
two example applications of the product and 
relate the earlier discussions to the real world. 
Finally, some system software is presented that 
handles all data transfer duties between master 
single board computers and intelligent slaves on 
the MULTIBUS system bus. More detailed 
information on many of the topics covered in this 
note can be found in the related publications 
listed in the front-piece. 


II. OVERVIEW 
Intelligent Slave Architecture 


Over the years, component technology has 
increased at a rapid pace going from discrete 
components (eg. transistors) to integrated circuits 
(eg. TTL devices) to programmable peripheral 
controllers (eg. Intel 8251A Universal Synchro- 
nous/Asynchronous Receiver/Transmitter) to 
fully intelligent slave devices (eg. Intel 8041A 
Universal Peripheral Interface). At the system 
level the evolution followed a similar path using 
the increasing component technology to create 
more and more powerful system building blocks. 
The iSBC 508 I/O board used TTL logic to provide 
digital I/O expansion for iSBC computers. The 
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iSBC 534 board took advantage of programmable 
LSI devices to provide a programmable commu- 
nications expansion board. Now, with the advent 
of the iSBC 544 Intelligent Communications 
Controller, a new level of system capability is 
made possible with the fully intelligent slave 
controller. 


The cornerstone of the intelligent slave architec- 
ture is the dual port memory. Through the use of 
this shared memory space, a fast and efficient 
protocol can be established to allow for coopera- 
tion between master and intelligent slave in 
solving the needs of the application system. In 
addition to the shared memory, the CPU on the 
intelligent slave also has some local RAM and 
local PROM storage for programs. By using this 
architecture the advantages of multiprocessing 
and Direct Memory Access (DMA) controllers are 
blended together. Unlike DMA controllers, the 
intelligent slave works totally within its own data 
space. Therefore, it is not affected by bus traffic 
nor does it add to this traffic. And, since the on- 
board CPU gets its instructions from local PROM 
instead of predefined hard-wired logic or micro- 
code, the user has total flexibility in defining the 
functions the intelligent slave will assume in the 
overall system. 


Although the contents of an intelligent slave 
make it look very similar to a single board 
computer, the assumption of the slave role pro- 
vides a distinct advantage. By performing duties 
for a master single board computer, the slave 
relieves the master of low-level processing duties 
and at the same time is itself relieved of system 
responsibilities. | 


In order to position the iSBC 544 product and 
outline what features it brings to the application 
system it is necessary to define the functions 
involved with communicating data. The three 
main functional divisions are illustrated in Fig- 
ure 1. At the lowest level the physical intercon- 
nection is maintained. This level involves such 
standards as RS232C which defines the require- 
ments for transmitting bits from point to point. 


The data transmission level involves the transfer 
of bytes and/or blocks of data from devices to 
computers and from node to node in computer 
networks. The hardware dependent software 
such as interrupt service and device polling is 


DATA PROCESSING 


PHYSICAL INTERCONNECTION 


Figure 1. Layering of Communication System Functions 


part. of this level as are handlers for. standard 
protocols such as SDLC, HDLC, Bisync and X.25 
or special purpose schemes and custom protocols. 


The highest level performs the actual processing 
of the data and calls upon the lower levels to move 
the: data from place to place. The application 
software resides at this level as do some high level 
software functions such as program to program 
and process to process communications packages. 


Now that we have a map of system functions to 
guide us, it is possible to gain an understanding of 
the usefulness of a product like the iSBC 544 
Intelligent Communications Controller. If an 
iSBC 534 board (which contains four USART 
devices) was included to handle the expansion of 
serial I/O capacity the mapping of system 
functions would look like that shown in Figure 
2. The four USARTs on the board would handle 
the physical interconnection but due to the lack of 
intelligence on the board the master CPU would 
be burdened with all of the data transmission 
duties in addition to its real duty, data processing. 


When an iSBC 544 board is used in the system, 
the mapping of system functions is as shown in 
Figure 3. The physical interconnection is still 
handled by the USARTs on the board but now the 
on-board CPU can be programmed to assume the 
data transmission duties. With an intelligent 
slave in the system, the master CPU is freed to 
concentrate on the data processing functions and 
the end result is that each function in the system 
is handled in the most efficient manner possible. 
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The iSBC 544 Board 


The iSBC 544 Intelligent Communications 
Controller contains: 


e An Intel 8085A CPU operating at 2.76 MHz. 


e Sockets for up to 8K bytes of read only memory 
(user can choose Intel 2716, 2316E or 2732 
devices). 


e 16K bytes of dynamic, dual port Random 
Access Memory (RAM). | 


e 256 bytes of static local RAM. 


e Four Intel 8251A USARTs with programmable 
baud rates. 


° Two Intel 8253 Programmable Interval Timers. 


e Intel 8155 parallel interface providing 22 

_ parallel I/O lines and one 14 bit interval 
timer. Various input and output lines are 

_ dedicated to provide an interface to a Bell 801 
or equivalent Automatic Call Unit (ACU). 


@ 8259A Priority Interrupt Controller. 


Il. HARDWARE CONSIDERATIONS 


This section of the application note will focus on 
the iSBC 544 hardware and will outline the 
features of the board and its uses. Appendix A 
contains simplified logic diagrams of the iSBC 
544 board which can be referenced in the follow- 
ing discussions. 


Two Mode Operation 


The iSBC 544 board is capable of operating in one 
of two modes; 1) intelligent slave and 2) stand- 
alone communications computer. The mode can 
either be set with a switch or it can be “toggled” 
via a software driven flip-flop on the board. In 
the intelligent slave mode the CPU on the iSBC 
544 board operates strictly within its on-board 
resources. Communications with 8-bit and 16-bit 
master single board computers is accomplished 
through the dual port memory. Since the on- 
board CPU executes code out of its local PROM 
program storage the system designer is free to 
define which functions the slave will assume in 
the system design. As discussed earlier, this 
could include all or part of the system data 
transmission duties or could involve application 
specific duties such as terminal format control, 
code conversion or terminal input editing.’ 
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In the stand-alone mode, the logic on the board 
disables off board access to the dual port RAM 
and the bus buffers are used to allow the on-board 
CPU to access expansion memory.and I/O on the 
MULTIBUS system bus. In this mode the iSBC 
544 board drives the bus busy (BUSY/) control 
line active disallowing any other bus master 
access to the bus. The stand-alone communica- 
tions computer is capable of performing all of the 
functions of the applications system. Referring 
once again to the diagram of the functions of a 
communication system, the stand-alone commu- 
nications computer, with or without system 
expansion, is responsible for all data transmis- 
sion and data processing functions. In small 
applications requiring multiple serial lines the 
stand-alone iSBC 544 controller is a perfect fit. 


In very special circumstances it is possible to 
share the system bus by toggling the mode set 
flip-flop between master and slave mode. Figure 4 
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TRANSFER 
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Figure 4. iSBC 544 Controller Running iSBC 204 
Disk Controller 7 a 
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shows the flow chart for a routine (code in 
Appendix. B) that makes use of the “software 
switch” to operate an iSBC 204 Diskette Control- 
ler. Using the iSBC 544 board in a system with 
DMA devices is not recommended except in cases 
where DMA accesses are short and relatively 
rare. The use of the CPU for the handling of other 
system devices could seriously degrade its 
performance as a communications controller. 
However, this capability could be extremely 
useful in a system such as a small message store 
and forward where the disk traffic is not heavy 
and including a CPU card just to handle the disk 
would be wasteful. Use of the “software switch” 
to share the bus with another iSBC CPU is not 
advised because of the amount of protocol that 
would be required to keep the CPUs from interfer- 
ing with each other on the bus. 


Dual Port RAM 


Figure 5 illustrates the dual port RAM memory 
array on the iSBC 544 card. A triple bus architec- 
ture is used to allow other MULTIBUS bus 
masters access to the RAM on the intelligent 
slave. Both the on-board CPU’s bus and the 


MULTIBUS system bus are connected to the dual 
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Figure 5. Dual Port Control Logic 
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port controller. From here the dual port bus is 
connected to the 16K of dynamic RAM memory. 
Memory transfer requests from either of the first 
two busses are handled by the dual port control 
logic with the on-board CPU being given priority 
if contention arises. The local CPU i is favored so 
that it is not overly delayed in handling its time 
critical functions. 


The address mapping of the dual port memory on 
the iSBC 544 is diagrammed in Figure 6. The user 
can enable access from the MULTIBUS system 
bus to 0, 4K, 8K or all 16K of the RAM on each 
iSBC 544 board. The dual port control logic 
decodes the full 20-bit address and provides an 
8-bit data path to the bus. For these reasons the 
iSBC 544 board is compatible with 8080A, 8085A 
and 8086 based single board computers. The user 
can also select the block of addresses on the 
system bus to which the iSBC 544 RAM will 
respond. 


MULTIBUS iSBC 544 
ON-BOARD 
ADDRESS. 


SPACE 


" DEDICATED 
_ STATIC RAM 


ROM/PROM 


X = ANY PAGE ADDRESS, 0 TO F(HEX) 


Figure 6. Address Mapping on Dual Port RAM Block 
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When accessed by the on-board CPU, the dual 
port RAM always appears at 8000H. If the iSBC 
544 board is operating in the stand-alone compu- 
ter mode, the board is capable of generating the 
16-bit bus address supported by the 8085A CPU. 


Interrupt Structure 


The interrupt structure of the iSBC 544 controller 
is designed to handle the heavy load imposed by 
the inherent real-time nature of the communica- 
tions application. An 8259A Priority Interrupt 
Controller handles the four receiver and transmit- 
ter ready interrupts from the 8251A devices and 
provides vectored interrupts using one of many 
available priority schemes. In addition to the 
eight interrupt sources handled by the 8259 there 
are various others that can be connected directly 
to the vectored interrupt inputs on the 8085A 
(RST 5.5, 6.5, 7.5 and TRAP). One interrupt is 
generated by the dual port control logic whenever 
a byte is written into the base address of the dual 
port memory by an offboard CPU. This interrupt, 
the flag interrupt, is cleared automatically when 
the on-board CPU reads the byte and is useful 
when designing a master-slave protocol since it 
provides a unique interrupt to each slave in the 
system. | | 


If the 8251A devices are used to interface to 
modems the loss of carrier and ring indicator 
interrupts from all four channels need to be 
connected to 8085A interrupt request inputs. This 
is accomplished with four input OR gates tying 
the eight sources into RST 6.5. The ring indicator 
and carrier detect lines can also be monitored 
through a parallel I/O port. This port would be 
read in a polled system to determine status or 
could be used along with the OR-tied interrupts to 
determine which channel is sourcing the current 
interrupt. 


The remaining interrupt sources come from the 
extra timer/counters and from the MULTIBUS 
interrupt lines. In addition to receiving interrupts 
from the bus, the iSBC 544 board has the 
capability of generating MULTIBUS interrupts 
using the Serial Output Data (SOD) line on the 
8085A CPU. . 


Modem and Autocall Interface 


The iSBC 544 controller uses 8251A and 8155 
devices for interface to modems and an autocall 


unit respectively. All of the necessary handsha- 
king signals concerned with the modem interface 
are connected to the 8251A and the carrier detect 
and ring indicator signals, as previously men- 
tioned, can be connected to interrupt inputs. The 
8155 parallel ports are wired as shown in Figure 
7. Allofthe commonly used signals defined in the 
EIA RS-366 specification for interface to an 
autocall unit are provided. The software neces- 
sary for handling the ACU becomes a simple 
matter of responding to the ACU requests and 
sending out the BCD digits representing the 
number being dialed. In addition to the ACU 
interface, the 8155 monitors various signal states 
and provides software reset capabilities for the 
USARTs and some interrupts. 


IV. SOFTWARE CONSIDERATIONS 


Software for the iSBC 544 ICC falls into three 
main categories; device programming, master- 
slave protocols, and communications support. 
Each of these three topics is covered in the 
following section with the aim of defining the 
software requirements and functions of the iSBC 
544 board. 


Device Programming 


The main sources of the power and flexibility of 
this product are the programmable LSI devices on 
the board. The first duty of the on-board software 
is programming these devices to handle the 
specific task at hand. To start with, the 8251A 
USART can be programmed for synchronous or 
asynchronous operation. In synchronous mode 
the user specifies even, odd or no parity and either 
external or internal sync detect with one or two 
sync characters. In the asynchronous mode the 
programmer selects the parity, the character 
length (5, 6, 7 or 8 data bits), the framing control 
(1, 1% or 2 stop bits) and the baud rate scaling 
factor (input clock frequency divided by 1, 16 or 
64). | | 


The 8253 Programmable Interval Timers provide 
the receiver and transmitter clocks for the 
USARTs and, along with the 8251A baud rate 
scaling factor, are programmed by the software to 
provide the desired communications frequency. In 
addition, two additional 16 bit timers are left 
available to the applications programs to be used 
as event counters, real-time interrupts, etc. 
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Figure 7. 8155 Pinout Definitions 
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- FLAG INTERRUPT: 1 = TRUE 
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The 8259A Priority Interrupt Controller is 
programmed to vector all interrupts through a 
jump table in memory. Also, the device provides 
software selectable priority schemes and an 
interrupt mask register for een auras anterrapt 
management designs. 


Last; but not least, the 8155 Preararamable 
Peripheral Interface provides various software 
controlled input and output ports as discussed in. 
previous sections. One specific point to remember 
is that the power on state of the 8155 clamps the 
reset signal to the USARTs active and must be 
removed by programming the 8155 before com- 
munications can begin. | 


Master- Slave Protocols | “ 


If an application system is visualized ab the 
highest level it appears to be a computer with 


various inputs and outputs as depicted in Figure | 


8a. If this computer is broken down into a master 
CPU and one or more intelligent slaves, great 
increases in efficiency and system throughput 
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can be realized by distributing the duties between 
the CPUs (Figure 8b). Once this split is per- 
formed, some well defined means of communica- 
tion between master and slaves needs. to be- 
defined so.that the processes that execute on the: 
different machines can cooperate. This means of. 
communication takes the form of a protocol 
followed by both master and slave. 
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Figure 8a and 8b. ‘System Software Block Diagrams : 
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The intelligent slave architecture was designed to 
simplify the development of the necessary 
protocol. The shared memory space in the dual 
port RAM provides a large communications 
buffer area where data and commands can be 
transferred using normal memory transfers. Data 
structures of any needed complexity can be built 
in this memory area and accessed by both master 
and slave. The flag interrupt can be used to 
provide a unique synchronization signal from a 
master to a given slave. In addition, the MULTI- 
BUS interrupt lines can be used to provide extra 
signals in both directions. As we shall see in the 
system software section, these basic tools can be 
utilized to design a general purpose data transfer 
mechanism which isolates the applications 
processes from the worries of protocols and 
synchronization. 


Communications Support 


The previous software topics dealt mainly with 
the system overhead that must be handled by the 
communications processor. The larger and more 
important duty of the CPU is dealing with the 
application at hand—communications. 


When configured as an intelligent slave to some 
master iSBC CPU board, the iSBC 544 board 
works to offload the master of communications 
related functions and at the same time is itself 
relieved of a major share of the system overhead 
and can be tuned to provide the highest possible 
throughput. With this combination, more com- 
plex applications can be tackled where the 
number of lines and the line frequencies are 
greatly increased. Multiple systems can be 
employed to provide a network facility with the 
iSBC 544 board now handling the network 
protocol in addition to its other duties. The 
architecture of the iSBC 544 controller is designed 
to simplify the user’s software development 
process. The board can be programmed to handle 
many possible data transmission functions from 
simple line protocols to terminal control to link 
protocols and all the way up to network protocols. 


In the stand-alone mode, the iSBC 544 board can 
assume total responsibility for the application. 
This can be done with on-board resources only or 


can include the support of offboard expansion like 


the iSBC 534 four channel serial controller. Appli- 


cations of the stand-alone controller could include 
cluster controllers, peripherals managers, line 
concentrators or any other small system. 


V. THROUGHPUT ANALYSIS 


This section of the application note deals with 
studies that have been done to quantify the 
performance of the iSBC 544 board in both the 
stand-alone and intelligent slave modes. After 
describing the various test configurations and 
assumptions the data will be presented in 
graphical form and analyzed. The graphical data 
can be found in Appendix C. 


Stand Alone Throughput 


The first two tests were run to determine the 
absolute best case throughput of the iSBC 544 
board configured as a stand-alone computer. Fig- 
ure 9a shows the iSBC 544 controller continuously 
outputting data from four buffers to the four 
USARTs. Figure 9b shows essentially the same 
setup with eight channels, four on the iSBC 544 
board and four on the iSBC 534 expansion 
card. In each configuration the 8251A was run in 
synchronous mode and the baud rate was incre- 
mented until the transmitter empty signal from 
the USARTs became active. Further increments 
of the baud rates would not have resulted in 
higher throughput since the CPU was already 
spending 100% of its available time responding to 
USART service requests. 


The maximum rate for the first configuration 
(iGSBC 544 board only) was 32,311 baud per 
channel. When the iSBC 534 expansion board 
was added a rate of 12,186 baud per channel was 
achieved. The drop in baud rate was due to the 
extra processing required by the offboard logic 
(eg. reading 8259 interrupt controller on the iSBC 
534 board to determine which device is requesting 
service). 


It should be noted that the serial throughput tests 
were run with almost no overhead and no actual 
processing of the data involved. The reader is 
expected to apply information on the amount of 
overhead expected in each individual application. 


_ For instance, if the application code for a given 
_ system is expected to utilize approximately 40% of 


the available CPU time and we wish to run four 
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Figure 9a and 9b. Stand-Alone Throughput Configurations - 
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full duplex channels in asynchronous mode the 
estimate of maximum baud rate would take the 
following form. 


32,331 baud per channel — 40% = 19,398.6 baud 


19,398.6 baud per channel synchronous x 10/8 
= 24,248.25 baud asynchronous 


24,248.25 baud per channel half duplex/2 = 
12,124.125 full duplex 


Therefore, the maximum standard baud rate 
would be 9600 baud per channel in full duplex 
asynchronous mode. 


Intelligent Slave Throughput 


The remaining four configurations were set up to 
determine the effectiveness of the intelligent slave 
in the overall system. The general system config- 
uration is illustrated in Figure 10. The boards 
surrounded by the box represent the systems 
under test. The disk controller and two iSBC 
80/20 single board computers were active on the 
bus to simulate the normal bus traffic load in an 
application system. Various bus duty cycles were 
created using the computers and the disk control- 
ler to perform tasks that resulted in fixed bus 
utilization. 


Figure 10. General System Configuration for 
Throughput Testing 


In each configuration a single full duplex channel 


was set up with the input provided by another 
CPU. Only those functions dealing with system 
overhead were included and the data measured 
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reflected the amount of bus time, master CPU 
time and slave CPU time left available to 
applications oriented tasks. In each case this 
percentage of time available was measured as the 
baud rate was stepped up so that a graph could be 
constructed showing time available as a function 
of transmission speed. | 


CPU free time was measured using a counting 
program running in the background. After each 
USART interrupt the counter was started. As 
interrupts from other sources came in the count- 
ing was preempted and then resumed after 
servicing the interrupt. When the next USART 
interrupt occured, the counter contents were 
examined and if the value was lower than the 
stored value the current value became the stored 
value. After ten minutes the stored value was 
retrieved and used as an indicator of the worst 
case time available between interrupts. 


System bus utilization was measured using the 
circuit shown in Figure 11. The voltage measured 
by the digital voltmeter represented a time 
average of the voltage at the output of the flip- 
flop. A calibration chart was created using a 
pulse generator to simulate various duty cycles 
and then this chart was used to measure bus 
activity while the test was running. 


VOLTMETER 


+ _~ 


BUSY/ 


BCLK/ 


Figure 11. Bus Free Time Measurement Circuit 


Configuration 1 is shown in Figure 12. This 
system uses a typical method of communications 
expansion with the iSBC 80/30 single board 
computer handling the lines directly via the serial 
I/O ports on the iSBC 534 I/O controller board. 
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Figure 12. System Throughput Test, Configuration 1 | 


The second configuration (Figure 13) illustrates 
the performance of the traditional DMA control- 
ler approach. If the communications controller 
had DMA logic instead of a dual port memory and 
transferred data directly into system memory the 
performance would be as observed in this test. 
In configuration 3 (Figure 14) the iSBC 544 board 
was used in the intelligent slave mode. This 
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configuration differs from the second in that 
memory transfers involved only local memory 
and bus access was not required on a per 
character basis. 


The fourth and final. Seenautaicn swaait to 
identify the loading that additional intelligent 
slave controllers would impose on master CPU 
time and bus free time. Figure 15 shows the 
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Figure 18. System Throughput Test, Configuration 2 
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Figure 15. System Throughput Test, Configuration 4 
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configuration with two iSBC 544 boards execut- 
ing identical programs. 


The graphical presentation of the results is split 


into two sections. The first three graphs (Graph 1 | 


through Graph 3) show the relationship between 
baud rates and the master CPU, system bus, and 
slave CPU utilization. All of these results are 
based upon tests with 30% induced bus traffic (i.e., 
the two iSBC 80/20 computers and the iSBC 204 
disk controller were active.) 


In graph 4, processor free time is graphed as a 
function of bus traffic. The processor in this case 
is the one actually involved with the data on a per 
character basis (i.e., 
figuration 1, iSBC 80/30 board simulating DMA 
Controller in configuration 2, and iSBC 544 board 
in configuration 3). | 


Finally, graph 5 illustrates the maximum attain- 


able baud rate for each configuration as the bus 


traffic is increased. 


All of the graphs identify the relative perfor- — 


mance difference between the configurations. 
Absolute numbers are not presented due to the 
fact that the overhead imposed by the test 
software affects the CPU time being measured. 
Since the overhead applies equally to all config- 
urations, the relative performance indications are 
valid... 


Based upon the data presented, the DMA control- 
ler and intelligent slave use 3 times less CPU time 
than an I/O controller. Also, the iSBC 544 
intelligent slave generates 12% and 6% less bus 
traffic than the I/O controller and DMA control- 


ler respectively. Finally, the intelligent slave uses _ 
8% less slave CPU time than the DMA controller 


approach. 


The earlier discussion that dealt with the intelli- _ 


gent slave architecture pointed out that the 
distribution of intelligence would offload the 
master CPU so that it would retain sufficient 


processing power for the actual application, 


whatever that may be. In addition, it was stated 
that the assumption of the slave role would relieve 
the slave CPU of system overhead and at the 
same time reduce system bus traffic. All of these 
assumptions are supported by the results of the 
testing presented here. 
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iSBC 80/30 board in con- — 


The second set of graphs identify the effects of 
bus traffic on the performance of the various 
components of the system. The main observation 
to be made in this sequence is the drop in CPU 
free times and maximum baud rates that occurs 
when the bus gets busy. This effect is observable 
in the communications processor free time when 
the iSBC 534 expansion board or the DMA 
controller configuration is used. No effect is 
evident in the ace with an iSBC 544 
board. 


The cause of this effect is the amount of bus 
access required by each configuration to move the 
characters from the USART to or from the 
buffer. With an iSBC 534 board the master CPU 
receives an interrupt, polls the offboard 8259 | 
interrupt controller, reads in a character, stores it 
in system memory and sends an end of interrupt 
command to the offboard interrupt controller. 
When the iSBC 80/30 computer receives an 
interrupt all processing is performed onboard 
until a bus access is required to move the data 
byte from/to memory. In the case of the intelli- 
gent slave, all processing for a character is 
performed onboard. Thus; as the system bus 
becomes very fully utilized, the delays encounter- 
ed in receiving bus access by the first two 
configurations become significant. 


The fourth configuration, which was set up to test 
the effects of adding more intelligent slaves, 
shows that extra slaves cause no appreciable 
increase in system load. All of the data points for 
two slaves were identical to the points for one 


slave in graphs 1 through 5. 


VI. APPLICATION EXAMPLES 


A Distributed Control System 


The potential applications for a product like the 
iSBC 544 communications controller are almost 
unlimited and not restricted to the traditional 
Data Communications market. The first applica- 
tion example that is studied concerns industrial 
automation. Due to the fact that the system is 


- distributed and requires a generalized network, 


the iSBC 544 board is a natural prospect to handle 
the communication links between the various 
nodes i in the system. : 
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Design Requirements 


The system to be designed is intended to provide 
the framework for a family of distributed control 
systems where the configurations and the objects 
to be controlled vary from system to system. Fig- 
ure 16 shows the general picture of the system. 


Figure 16. General Diagram of Distributed 
Control System 


The host is responsible for providing supervisory 
control and a high-level human interface. The 
system can be expanded as shown in Figure 17 
where the controllers attached to the host are 
replaced by intermediate nodes which contain 
controllers or other nodes. This process can be 
continued as far as is necessary to provide the 
needed number of controllers. Each controller in 
the diagram represents a localized closed loop 
control system that is tailored to the specific 
application. | 


The following system requirements need to be met 
by the computer network: 


e The host CPU must have sufficient computa- 
tional power to handle the human interface, 
mass storage management, supervisory control 
calculations and network control. 


e The host CPU must not be overly burdened by 
low-level communications functions if it is to 
handle the other duties assigned to it. 


e Node controllers must be capable of handling 8 
medium speed lines and also modems and 
autocall units since the nodes or controllers 
attached may be remote. 


Figure 17. Expanded Diagram of Distributed Control System 
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@ The message 'ianemisaion format must be. 


independent of the configuration and end 
j application. ‘The nodes in the network must be 
capable of passing through messages with and 

~ without interpreting the contained data. 


e The system must be capable of auto- configura- 

_. tion (since the network configuration is tailored 
7 to the specific application, the host must be 

. able to automatically determine the setup at 
- power on). 


e Each node controller is responsible for verity- 
- ing the integrity of the nodes attached. 


System Configuration - 


Based upon the design criteria and the penal: 
mark information the chosen configuration uses 
an iSBC 86/12 Single Board Computer as the host 
with an iSBC 544 intelligent slave handling the 
‘communications load for the CPU. The USART 
on the CPU board will talk to the local terminal 
and an iSBC 206 Hard Disk Controller will be 
used to provide up to 40 0 Megabytes’ of mass 
storage capacity. 


‘The requirements for the node controllers ss to. 


an iSBC 544 board configured as a stand-alone 
communications computer with an iSBC 534 


board as expansion to provide the necessary 8 . 
lines. The throughput data indicated a raw 


throughput value of 12K baud on each channel. 
With the data rates expected being far below this, 
sufficient time will be left over for background 
functions. Thus, the software requirements for 
each node can all be met by the CPU on the iSBC 
544 board and the inclusion of an expansion 
board does ‘not necessitate another iSBC compu- 
ter. mec | | : 


A typical controller in the system would look like 
that shown in Figure 18. The iSBC CPU handles 
the local closed loop control, using parametric 
information sent from the host. This information 
would typically include setpoints, tolerances and 
alarm limits. The serial channel on the CPU will 
be used to maintain the link to the next level in 
the network. 


Preliminary Design 


The message format that the system uses is .. 


shown in Figure 19. When multiple nested levels 


DIGITAL INPUTS. 


. ANALOG ~ 
“ CLOSED Loop ‘~ OUTPUTS 
CONTROLLER © | | 


- 1$BC'80/10A SINGLE BOARD 
COMPUTER WITH iSBC 732 
ANALOG I/O BOARD _ 


ANALOG © 
INPUTS 


SERIAL 
LINK DIGITAL OUTPUTS 


Figure 18. Typical Controller in Distributed System 


Figure 19. Message Format 


A FRAME | Ff 


ADDRESS 


\ 


Figure 20. Nested Level Address Information 


of nodes are used the data area of the message 
contains command and address information for 
the next level down (Figure 20). Interpretation of 
the commands in a given message is done on an 


individual basis except for a set of system-wide 


commands (eg. IDENTIFY is a system command 
meaning respond with your ID code). The flexi- 
bility afforded by this scheme can be extremely 
useful in a system where the end applications and 
configurations may be quite diverse (eg. a node 
controller that is processing a transmit command 
may be the only one that knows that it is sending 
to another node via a phone line and thus it 
interprets the contained data differently than 
another node would). The level of intelligence 
and the ease of programming of the iSBC 544 
board make this generalized transmission scheme 
possible. | 
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The simplest means of auto-configuration re- 
quires each controller in the system to send an 
identity message to the nearest node. This node 
would know the logical address of the controller 
that sent the message and would attach this 
address to the message and retransmit it to the 
next level as illustrated in Figure 21. This process 
would be repeated until the host is reached and 
would contain, at this point, all necessary address 
information to reach the given controller. 


[ADDRESS] ADDRESS | (D. 


CONTROLLER 


Figure 21. Auto Configuration’ . 


The human interface on the host would provide a 
mapping mechanism to attach meaningful 
symbolic names to the various nodes in the 
system. This labeling, along with the application 
specific control algorithms, make it possible to 
say something like “lower the temperature on the 
third floor to 68°F’’. The host, breaks this 
information down into setpoints and tolerances, 


uses the map to determine the path to the node(s) 
responsible for the third floor and transmits the 
information through the network. 


Each node controller in the system has the added 
responsibility of verifying the integrity of all the 
nodes attached to it. This duty can be handled by 
periodic background commands issued from the 
host and propagated through the network. Each 
node is responsible for passing the command 
along and also polling the nodes attached to it 
and reporting back any error conditions. 


Summary 


Through the use of a powerful 16-bit iSBC Single 
Board Computer, various low-cost 8-bit iSBC 
CPUs and the iSBC 544 communications control- 
ler, a flexible and extensible distributed control 
system is easy to design. The dual nature of the 
iSBC 544 board provides both an intelligent front 


-end to the host computer and a high-speed stand- 


along nodal concentrator. The ability to individ- 
ually customize the software on each controller 
provides for an easily expandable system design. 


Terminal Cluster Controller 


The second application example concerns itself 
with a terminal cluster controller. The system 


shown. in Figure 22 uses a number of ‘‘dumb” 


terminals and makes them appear “intelligent” 
via a local microcomputer system. The local 


microcomputer interfaces with the operator and 


accesses a local data base to provide an inquiry 
and data entry service. When necessary, the local 


-microcomputer is capable of calling the host via 


an autocall unit and exchanging information and 
updates to the data base. 


Design Criteria | | | 
The terminal cluster controller must meet the 
following criteria: 


e Support must be provided for from four to 
sixteen operator terminals all running at rates 
up to 2400 baud. 


e Line editing on input must be provided (delete 
characters, delete lines and pause output). 
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Figure 22. Terminal Cluster 


e Support for the terminals must be configurable 
in that certain stations may require different 
screen formats. 


e Support for an optional hard copy device must 
be allowed for. 


e A considerable amount of CPU free time must 

be available after the basic terminal facilities 

are included. This is due to the fact that the 
data base management software to be written 
_to run on the master single board computer will 
be extensive. 


e Type ahead would be a desired feature Sitios the 
processing on the master CPU after a line of 
input has been transmitted may cause a delay 
in responding and we would like to have the 
ability to continue entering input while waiting 
for the response. 


System Configuration | | 

The specific iSBC products needed to implement 
the system described are the iSBC 80/30 Single 
Board Computer with an ISBC 032 RAM Expan- 
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BASE 


sion Board, an iSBC 206 Hard Disk Controller 
and one to four iSBC 544 Intelligent Communica- 
tions Expansion boards. Intel’s RMX/80 Real- 
Time Multitasking Executive will provide the 
basis for the software system and will include 
disk file support for the iSBC 206 controller 
through DFS/80. The full system configuration 
is illustrated in Figure 23. 


BLOCK DIAGRAM 
iSBC 206 iSBC 032 
BOARD BOARD 
MULTIBUS SYSTEM BUS 


iSBC 544 iSBC 544 iSBC 544 can a. 
| BOARD BOARD BOARD 


Figure 23. Terminal Cluster Controller System. 
| Configuration | 
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Preliminary Design 


The first design decision to be made involves the 
distribution of system functions. Due to the 
requirements for line-editing and type-ahead the 
software for processing characters input from the 
terminal keyboards will be somewhat lengthy. 
The standard terminal output handler will be 
very small but provisions for special screen 
format controls and/or hard copy devices must be 
allowed for. All of these requirements lead to the 
use of the iSBC 544 controller for all terminal 
functions. If the master CPU were burdened with 
all of these duties it would be unable to adequately 
perform its data base management functions. 
The fast CPU and 8K PROM capacity of the iSBC 
544 board will be more than adequate for the task 
at hand. | | 


The throughput tests indicate that the loading 
imposed by expanding the number of terminals 
(and therefore the number of iSBC 544 boards) 
will not adversely affect the performance of the 
rest of the system. Master CPU free time and bus 
traffic data for two intelligent slaves in the 
system were identical to the numbers for one 
slave. Thus, since the iSBC 80/30 single board 
computer and the MULTIBUS system bus can 
handle one iSBC 544 controller they can also 
handle the maximum of four controllers that may 
be required by this application. The only observ- 
able effect will be caused by the load the extra 
operators impose on the data base software itself. 


The software needed for the iSBC 544 board is 
now defined and divided into three major pieces; a 
terminal input handler, a terminal output handler 
and system software to support the handlers. 
Since the input and output handlers are invoked 
via USART interrupts, all that need be done is to 
write a single routine for each handler and have it 
talk to all of the devices on the board. This can be 
accomplished by vectoring the proper interrupts 
to the entry point of the routine and then polling 
the 8259A interrupt controller to determine which 
device needs servicing. 


The standard terminal input handler needs to 


read in the available character from the USART, | 
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check it to see if itis a special command character 
and, if not, store it into a buffer. If a command 
character is encountered, the handler will respond 
by performing the appropriate operation. 


The standard terminal output handler simply 
takes characters out of a buffer upon interrupt 
from the transmitter and sends them to the 
appropriate USART. Ifa different output handler 
needs to be substituted for a special terminal or a 
hard copy device, a new routine can be included 
by modifying the interrupt vector address in the 
8259A jump table. 


Since the RMX/80 Real-Time Multitasking 
Executive is being utilized on the master CPU itis 
desirable to create an RMX/80 handler for the 
iSBC 544 boards that accepts and processes 
normal terminal handler request messages. In 
this manner, application tasks that formerly 
communicated with the on-board USART via the 
RMX/80 Terminal Handler can be made to talk to 
one of the devices on the iSBC 544 board by 
simply changing the address of an exchange. The 
following paragraphs, as well as paragraphs in 
the section on system software, assume a know- 
ledge of the RMX/80 Real-Time Executive. This 
knowledge is not necessary to use the information 
contained in this application note. Interested 
readers are referred to the RMX/80 references 
listed in the front-piece. 


Since this application can have from one to four 
iSBC 544 boards the RMX/80 driver will need to 
be configurable. A set of tasks and exchanges 
will be created for each terminal in the system. 
One task and exchange pair will accept and 
process terminal input request messages while 
another pair will process terminal output re- 
quests. 


The remaining piece of software that is needed by 
this system will provide the means for getting 
commands and data between the master and 
intelligent slave. Since this is a common need in 
any system utilizing an intelligent slave we will 
develop a general purpose scheme that can be 
used by any application. In this manner, a 
routine such as the terminal input handler can be 
written without any concern for how it will get the 
data it is inputting to the master CPU; all it need 
do is call upon a standard routine to “transmit” 
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the data.-With these thoughts in mind, the 
following. section discusses the system software 
developed for master-intelligent slave communi- 


cation. After the discussion of the system soft- 
ware we will revisit the software for the second 
application as an example of the use of the data 
transfer routines. = 


VII. SYSTEM SOFTWARE 


In the earlier discussion of master-slave protocols, 
the notion was presented of developing a general 
purpose data transfer scheme which would enable 
the applications routines on both the slave and 
master to operate without concerning themselves 
with protocols and synchronization. This scheme 
can be implemented by designing a set of 
primitive routines to handle the data transfer 
activities. Thus, Figure 8b is expanded as shown 
in Figure 24 and the applications processes now 
call upon the primitives to handle the communica- 
tions between the master and the slave. 


Data Transfer Primitives 


The basic mechanism used by this implementa- 
tion of the primitives is a wraparound quéue as 
shown. in Figure 25. Each 8251A device has 
associated. with it, in dual port memory, an input 
and an output queue each of which have a give 


. MASTER | — 


. MASTER 


APPLICATION 
SOFTWARE 


3 TOP. 
ce) ae Te _POINTER | - 


TAKE . 


' POINTER et 


MULTIBUS 
' SYSTEM 


BUS 


GIVE es 
POINTER. | sC, 


‘ BOTTOM ©. 


. < POINTER 


Figure 25. Wrap-around Queue Used by Data 
Transfer Primitives 4 


and a take pointer. The give pointer contains the 
address of the next location in the queue that is 
available for filling with data. The take pointer 
contains the address of the next byte in an output 
queue that has been filled and is available. A 
queue is empty when the give and take pointers 
are equal and it is full when the act of incre- 
menting the give pointer would make it equal to 
the take pointer. A wrap function is defined to 
increment a pointer such that’ an increnient past 
the bottom of the queue “wraps’ ’ the pointer 
around to the top of the queue. — ~~ F 


SLAVE 


SLAVE 
‘APPLICATION 


_ SOFTWARE 


APPLICATION SYSTEM | 


‘DATA 


TRANSFER <_-___________ 


- PRIMITIVES 


Figure 24. ‘System Software Diagram with Data Transter Primitives — 
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The primitives all make use of a queue informa- 
tion block located at the base address of the 
slave’s dual port memory (Figure 26). All pointer 
information is base relative to accommodate the 
needs of the two CPUs who have different 
memory maps. The two flag bytes carry informa- 
tion for master-slave and slave- master synchron- 
ization signals. 


MASTER ——> SLAVE 


SLAVE ———_> MASTER 


Figure 26. Queue Information Block | 


The set of primitives provides two distinct 
methods of information transfer, line oriented 
and byte oriented. The line oriented primitives 
are listed in Table 1. Both get$line and send$line 
transfer information between the queues and 
buffers provided by the caller. The disadvantage 


of this scheme is the number of memory moves 


needed to transfer information. The advantages 
of the line oriented method are the relative 
efficiencies and the simplicity of the EIETIAC 
from the calling routine. 


The byte oriented primitives (Table 2) allow the 
calling routine to transfer data directly into and 
out of the queues. An example of the sequence for 
putting a character into a queue is illustrated in 
Figure 27. The routine servicing the receiver 
ready interrupt calls next$space to get a pointer to 
the next available slot in the queue and then uses 
this pointer to transfer the data byte directly into 
the queue. The new$line, xmit, open$line and 
receive primitives are necessary since the global 
give and take pointers cannot be modified until 
all manipulations on the affected section of the 
queue are complete. If the pointers were modified 
continuously the routine gathering the data from 
the other side may see invalid data. 


/* OPERATOR TYPES “L” */ 


PTR = NEXT$SPACE (QUEVESNUMBER): 
VALUE = INPUT (USART$DATA$PORT); . 


LINES OF INPUT 


WAITING FOR 
MASTER PROCESSOR 


GIVE 


——__» 
BOTTOM 


_ Figure 27. Sequence for Putting Data Into Queue 


Table 1 


| send$line 


Arguments 


Queue$token, buf$ptr, count 
Returns: overflow . 


Queue$token, but$ptr, count 
Returns: Actual 


get$line 
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Line Oriented Primitives 


Inserts count characters into queue from buffer 
If insufficient room available, overflow indicates how many would not fit 


Retrieves count characters from queue and puts them in buffer 
Actual indicates how many were actually moved ' 
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The remaining primitive routines deal with the’ 
general purpose needs of the application software. 
with regard to interrupts, initialization and ‘status. 


checking. A full list of these support routines is. 
contained i in ‘Table. 3. 


There « are many ania this implementation 
and a few of them should be pointed out at this 
time. By. defining a general purpose:set of 


primitive routines to handle the data transfer, the 


actual means by which the bytes are transferred 
between slave and master is not visible to the 
calling routine. If the actual mechanism used 
needs tobe altered the change will not affect the 
application software as long as the same external 
interface is maintained. : 


Another important feature. of. the primitive 
routines.is the fact that. they do not interpret the 
bytes that are sent to them. Due to this fact, the. 
applications. routines are. free to send commands 
and. parameters interspersed with the. actual 
data: As an example, the terminal driver on an 
iSBC 544 board. might. perform. format control 
based upon table information. The master appli- 
cations. software could use the data. transfer. 
primitives to transmit commands and parameters 
to the slave to update.its format. control informa- 
tion. Another advantage of the fact that the data 
is not interpreted is that it allows the calling 
routine to determine what data gets sent along. 
For instance, a specific terminal might be 
transmitting ASCII code while the master 


Table 2 
Byte Oriented Primitives 


[rime [Nomen 


new$line Queue$token 


Sets up a queue for byte oriented input. 


next$space 


back$space.. 


xmit 


opensgline 


next$char 


receive 


a 


-get$status : 


set$interrupt 


—set$handler... 


s$init 


_mginit 


Returns: ptr 


Queue$token 
_ Returns: ptr 


Queue$token 
Returns: ptr 


Queue$token 
Returns: status 


Queue$token: 
Returns: ptr 


Queue$token 
Returns: ptr 


Queue$token 


Returns: status 


Queue$token 
Returns: status 


Queue$token, type 
Returns: status. 


. Queue$token, handler$adr .... |. 


Returns: status 


none 


~ none 


Ptr returned points to the first available byte. 


Increments the temporary give pointer to the next open space. 
Ptr returned either points to next byte or is zero Speenying full queue. 


Decrements temporary give pointer. 


Ptr returned either points to byte or is unchanged indicating that the 
global give pointer was reached. 


Closes off a line entered via byte mode by updating global give ptr to 
equal temporary give ptr. Status is either “normal” or “null”. 


Opens up a line for byte oriented output:: 


Ptr returned either points to the next. bytes or cis zero | Indicating a an- 
empty queue. 


Increments temporary take pointer. : . 
Ptr returned either pointe to next’ eye or is zero indicating an: 
empty queue. — geri ay 


_ Closes off a line retrieved in byte mode by updating global take an 


pointer to equal ey ptr. Status is either “normal” or “null”. 


Table 3: 


‘Support Routines 


Returns status of queue. Possible values are “normal”, “empty”, 
“full” and “null”. 


os Generates a slave ~ master or master — slave interrupt. Type code 0 
_ is illegal and codes 8H — OFH are reserved for use by the PUmnUNeS 


Inserts. address into, vector. anle used for handling interrupts 
described. above. : ee 


Called fon slave software to initialize. 


Called from master software to initialize. 
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software is expecting EBCDIC. The routine on 
the slave can very easily perform the necessary 
code conversion before stuffing the data into a 
queue. oe ores 


Sample Slave Software 


Given the existence of the primitive routines the 
applications routines on the slave and master can 
deal with the specific duties of each device. The 
following paragraphs revisit the code from 
application example 2, first for the slave and then 
for the master. Full code listings for these 
programs can be found in Appendix D. 


The flowchart for the terminal input handler 
resident on the iSBC 544 board is shown in Figure 
28. Support is provided for deleting characters 
(Rubout), deleting lines (control-X), pausing and 
resuming output (control-S and control-Q) and 
terminating lines (escape and carriage return). 
The sections of code reproduced below use this 
terminal input handler to present an example of 
the use of the data transfer primitives to enter and 
edit a line of input from a terminal. The byte 
variable value is based on the address variable 
value$ptr which is assigned by calls to the 
primitives. The routine var$inp inputs and 
returns a data byte from an I/O port specified by 
a calling parameter. This is necessary since the 
particular USART to be serviced is determined by 
reading the 8259A in-service register. 


/x case 17; rubouts; delete char x/ 


do; 

 newSptrsbacksspace (token); 
if new$ptr=length$ptr then : 

: dummy=echo(tokentl,.(pellj,1)3 
- else 

doz © 

dummy=echo(tokent1,.(BS,SP,BS),3)3 

ptr=newsptr; 

count=countel;3 

end; . 

end; 


Following this, the byte input is checked to see if 
it is a control character and if so a block within a 
DO CASE statement is executed. As an example 
of one of these blocks, if the character input was a 
RUBOUT the code sequence below is executed. 
The back$space primitive is called and a tempo- 
rary pointer is returned to a location in the queue. 
A check is made to determine if the line was 
empty and, if so, a bell is echoed to signal the 
operator. If the pointer returned did not indicate 
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an invalid RUBOUT the real pointer is assigned 
the value of the temporary pointer and a back- 
space, space, backspace is echoed to delete the 
previous character on the screen. Lastly, the 
character count for the current line is decre- 
mented. : 


VALUESPTR=NEXT$SPACE (QUEUESNUMBER) 
VALUE=VARSINP (USARTSDATAS PORT (NUM) 


); 


RECEIVER READY 
INTERRUPT 


SAVE 
STATE 


DETERMINE 
WHICH 
8251A 


GET 
CHARACTER 


CONTROL YES 


CHARACTER 
? 


NO 
ECHO 
CHARACTER 
PUT INTO 
QUEUE 


HANDLE 
IT 


INCREMENT 
COUNTER 
UPDATE 
- POINTER: 
NO 


END 
INTERRUPT 


STOP 
FURTHER ECHOING 


RESTORE 
STATE 


RETURN 


Figure 28. Flow Chart for Terminal Input Handler 


AFN-01931A 


In order to facilitate retrieval of the proper 
amount of information .on the master side, the 


first byte of each message is defined to contain 
the number of characters in the message. Thus, 
when the master routine needs a line of input he 
uses the first byte as a count to retrieve the full 
line. ~The requirement for type-ahead is met by 
this mechanism since the number of lines in the 


queue at a given time is limited only by the length 
of the queue. When a full line of input is finished, 
the terminal input handler generates a slave to 
master interrupt to signal the master routine who 
may be waiting for this.event.. 5 ss 


The flowchart for a minimal terminal output 
handler is shown in Figure 29. Upon receipt ofa 


TRANSMITTER 


EADY 
INTERRUPT 


DETERMINE 
WHICH 


SAVE 
STATE 


8251A 


ET 
CHARACTER 


YES DISABLE 
TRANSMITTER 


NO 


OUTPUT (USART) 
= BYTE~—PTR 


DECREMENT 
COUNTER 


IS QUEUE NO 


COUNTER-=0? 


_ INTERRUPT 
MASTER 


ND 
INTERRUPT 


RESTORE 
STATE 


ak 


RETURN 


Figure 29. Flow Chart for Terminal 


CLOSE 
LINE 


- OPENNEW. | COUNTER 
LINE =100 


Output Handler 
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transmitter ready interrupt the output handler 
requests a character from the appropriate queue. 
If one is available it is output to the USART. If 
the queue is empty, the transmitter is disabled. 
Whenever the master routine sends a line into the 
queue it will generate an interrupt to signal the 
slave handler and the transmitter will be reen- 
abled. A line is opened via a call to open$line and 
it is kept open until 100 characters have been 
retrieved via calls to next$byte. At this time the 
line is closed by a call to receive making the space 
available to be reused. After this, a new call to 
opengline starts the process over again. If the 
call to get$status shows that the queue was full 
prior to the call to receive, an interrupt is sent to 
the master to reawaken any routine that may 
have been waiting for room in the queue to 
become available. 


INPUT 
INPUT REQUEST 
EXCHANGE 


HANDLER 


UsER _\ 
| RESPONSE |———-> 


\ EXCHANGE / 
oh / 


OUTPUT { OUTPUT 
REQUEST 
aaa EXCHANGE 


Sample Master Software 


The RMX/80 handler for the master single board 
computer that will communicate with the soft- 
ware on the iSBC 544 board is diagrammed in 
Figure 30. In addition, the RMX/80 message used 
to convey information to the handler is shown on 
the right. The full software diagram is illustrated 
in Figure 31. 


The input driver tasks execute a reentrant routine 
that services a request exchange that is specified 
in an initialization block that is unique to each of 
the input tasks. The necessary information is 
extracted from the request message and the 
get$line primitive is called upon to get a line of 
input from the queue. Ifthe call to get$line for the 
length byte is unsuccessful the input task waits at 


. LINK 
3 - LENGTH 
TYPE 


RESPONSE EXCHANGE 
STATUS 


CHARSBUFF 


BUFFER ADDRESS 
COUNT 
; ACTUAL 


. USER _— | 
| RESPONSE (-— 
\ EXCHANGE / 


Figure 30. RMX/80 Handler for. iSBC 544 Board _ 
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. MASTER > 


> DATA -| - . RMX/80 — 
TRANSFER DRIVER 
PRIMITIVES ri oO 


Figure 31. Master Software with RMX/80 Handler 


the appropriate signal exchange for an interrupt 
from the slave indicating that a line is now 
available. Once the request is fulfilled the actual 
and status fields are set and the message is sent to 
the response exchange specified by the user. 


The output handler performs in a manner very 
similar to the input handler. Upon receipt of a 
request message the handler attempts to transfer 
the characters from the user buffer to the 
appropriate queue. If the attempt is unsuccessful 


(ie. the queue has insufficient room available) the - 


handler sends as many characters as will fit 
(count - overflow) and then waits for an interrupt 
from the slave indicating that room has been 
made available. This process is repeated until all 
of the data has been transmitted. As soon as the 


operation is complete the status field is cleared 


and the message is returned to the user specified 
response exchange. 


Since the number of iSBC 544 slaves in the 
system is variable as are the memory base 
address, device programming information and 


MASTER APPLICATION SOFTWARE 


USER. 
SOFTWARE 


queue sizes, some means of providing configura- 
tion information to the RMX/80 handlers is 
needed. This information resides in the mem- 
ory$allocation$module. Public variables are 
declared in this module that are used by the 
RMX/80 tasks to determine how many devices 
(and therefore how many tasks need to be created) 
are in the system and where in the system address 
space their dual port RAM is located. In addition, 
queue sizes and device programming information 
are specified here. 


VIII. SUMMARY 


The intent of this application note has been to 
introduce the reader to the concept of the 
intelligent slave architecture and show the 
versatility of the first product based upon this 
architecture, the iSBC 544 Intelligent Communi- 
cations Controller. The hardware and software 
aspects of the device were studied and results of 
benchmark tests were presented and studied. 
Finally, two example applications were worked 
out using the product as both a stand-alone 


- controller and as an intelligent slave. — 
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The bottom line is that the iSBC 544 controller, 
due to the advanced architecture around which it 
is designed, can be the means to the end for any 
application that requires communication. The 
dual nature of the controller provides the full 
power of a single board computer to the small 
application while the large system can make use 


of the fully programmabale intelligent slave to free 
the CPU for complicated processing duties. 


I would like to extend my gratitude to Dave 
Jurasek for the work on the throughput testing 
and to Jack Tyler Inman for aid in the design of 
the system software. | 
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Figure A-2. ISBC 544 Memory Block Diagram 
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A M80 :F1l:DMA5 44, M80 


ISIS-I1 8080/8¥85 MACRO 


LOC 


GH 30 
OBE4 
6GE5 
\0852 
4MFF 
6084 
GOVO1 
B02 


0080 


vs 2C 
80 2C 
OU 2E 
6030 
0031 
9034 
0035 


OBJ 


D3E4 
DB81 
AF 
C43960 
FB 

C9 


F3 
31FFBF 
D3E4 
CDOB8B 
3E@4 
D388 
3EFF 
D385 
3E40 
D385 
3EUO 
D384 
3EO@ 
D384 
CDOObD 
3E52 
D380 
CDHOb0 
3E91 
D381 


CDOaGa 


3E@2 
D381 
D3E5 


a 


tH 


tm 


LINE 
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ASSEMBLER, V3.0 ...  .. MODULE PAG 1 
SOURCE STATEMENT — 
$MOD85 ae | ee 
BASE EQU 80H © ;BASE ADDRESS OF 204 
MMSET EQU  G6E4H ;MASTER MODE SET ADDRESS 
MMRSET EQU  ®E5H ;MASTER MODE RESET ADDRESS 
READ EQU 52H> ;READ, COMMAND CODE - 
TCOUNT EQU — 4OPFH ;TERMINAL COUNT AND DMA MODE “OF 
DMAMOD EQU 04H © DMA, MODE «WORD 
TADDR EQU di ;TRACK ADDRESS 
SADDR EQU 2 ;SECTOR ADDRESS 
| DSEG , | 
BUFFER: DS 128 SECTOR 3UFFER 
: TEST OF CAPABILITY FOR 544 TO SHARE MULTIBUS 
; - WITH OTHER MASTERS. ROUTINE PROGRAMS THE 264 
; BOARD, INITIATES A READ TRANSFER, WAITS FOR 
; AN INTERRUPT AND THEN TRAPS TO ICE85 BREAK- 
; POINT AT. 266. 
a 
ASEG . : 
ORG 2CH. ?RST.5.5 ENTRY POINT 
OUT MMSET ;SET MASTER MODE © 
IN BASE+1 ;GET RESULT 
XRA . A | ;SET FLAGS | 
'CNZ | ERRTRP ;NON-ZERO RESULT; ERROR TRAP 
EI “2 | pREENABLE : 
RET ; CONTINUE .ON 
; MAINLINE ROUTINE © 
EXTRN INIT24 — °;204 INITIALIZATION ROUTINE 
EXTRN  WAITC ;WAIT FOR 204 NOT BUSY ROUTINE 
EXTRN °WAITP. ;WAIT FOR 284 PARAMETER REGIST! 
CSEG | | 
pI ';DISABLE.- i 
LXI SP ,OBFFFH ;SET STACK POINTER. 
OUT MMSET ;SET MASTER MODE FLIP: FLOP 
CALL INIT24 ;INITIALIZE 204 | : 
MVI ~A,OMAMOD ;SET OMA MODE 
OUT BASE+8 ee Ue ; 
MVI A, LOW (TCOUNT) ;SET CONTROL REGISTER 
OUT BASE+5 a a ee 
MVI A,HIGH(TCOUNT) ; 
OUT BASE+5 | ; oo = 
MVL A, LOW (BUFFER) ;OUTPUT LOW BYTE OF DMA ADDRESS 
OUT BASE+4 oy oe es 
MVI A,HIGH(BUFFER) ;OUTPUT HIGH BYTE OF DMA ADDRESS 
OUT BASE+4 ; : | 
CALL WAITC : ‘ 
MVI A, READ ;OUTPUT READ COMMAND © 
OUT BASE+® ; 
CALL WAITP ; : 
MVI A,TADDR ;TRACK ADDRESS. 
OUT BASE+1 | ; 
CALL WAITP. ; 
MVI . A,SADDR. ;SECTOR ADDRESS 
OUT BASE+1 a 
OUT MMRSET ;RESET MASTER MODE FLIP/FLOP 
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6034 FB 58 
0635 76 59 
6836 C38082 68 
61 ERRTRP: 
09839 76 62 
63 


PUBLIC SYMBOLS 


EXTERNAL SYMBOLS 
INIT24 E 0860 WAITC E 6000" 


USER SYMBOLS oe 
BASE A 6088 BUFFER D 6006. 
READ A 0052 SADDR- A 0082 


APPENDIX B (Continued) 


EI 
HLT 
JMP 


HLT 
END 


200H 


WAITP E 6008 


DMAMOD A 6604 


TADDR A 6081 


4144 


; ENABLE 

;ANO HALT ; WAIT FOR INTEF 
;TRAP TO ICE85 BREAKPOINT ‘AT 200 
ERROR TRAP 

;FOR NOW 


ERRTRP C 0639  INIT24 E 6000 “. .-ME 
TCOUNT A 40FF § WAITC E 0008 ‘WAI 
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AMBQ-: Pl: INIT2 4.M86 


ISIS-II 8080/8885 MACRO 


LOC 


8088 
OBE4 
QBE5 


OBJ 


00 69 ee ee 


O018 
8012 
OOFF 
OOFF 
000D 
6008 
0008 
8009 
4000 
0004 
TTL 
0020 
bvld 


o000 
6001 
6083 
oue4 
TL 
6008 
OOOA 
TThs 
600D 
OGUF 
6012 
0014 
0016 
ga19 
6013 


901d 


6028 
8822 
0024 
0027 
8629 


O02B 


O02E 
08 30 
0832 


CD99698 


Gs 


©) 


LINE 


wenn Um WD ee 


ASSEMBLER, 


SMOD85 
BASE 
MMSET 
MMRSET 
SEEK 
SPECFY 
BADTR1 
BADTR2 
NOBAD 
CTADDR 
CHARS 
SETTLE 
STEP 
LOAD 
TCOUNT 
DMAMOD 
BUSY 
PARFUL 
RESFUL 


INIT24: 


APPENDIX B.(Continued) 


EQU 
EQU 
EQU 


EQU 
- BQU 


EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 
EQU 


=e s~@ wo “OC 


se 


CSEG 

PUBLIC 
PUBLIC 
PUBLIC 


DI 
MVI 
SIM 
OUT 
OUT 
MvI 
ouT 
XRA 
OUT 
CALL 
MVI 
OUT 
CALL 
MVI 
ouT 
CALL 
MVI 
OUT 
CALL 
MVI 
OUT 
CALL 
MVI 
OuT 
CALL 


V3.0 


SOURCE STATEMENT 


80H 
OE 4H 
BE58 
69H 
358. 
10H 
18H 
OFFH 
OFFH 
@DH | 
08H 
03H 
09H 
4000 
04H 
80H 
20H 
10H 


PAGE =.1 


;BASE ADDRESS. OF 204 - 
:MASTER MODE SET ADDRESS 

;MASTER MODE RESET ADDRESS: 
;SEEK COMMAND 

;"SPECIFY" ‘COMMAND CODE 
;SPECIFY BAD TRACKS SURFACE 1 
;SPECIFY BAD TRACKS SURFACE 2 
;NO BAD TRACKS | 
;CURRENT TRACK ADDRESS NOT KNOWK 
;SPECIFY DRIVE CHARACTERISTICS 
;HEAD SETTLE TIME (SA8QO) 

;STEP RATE 

sHEAD LOAO TIME 

;sTERMINAL COUNT AND DMA MODE ‘OF 
;DMA MODE WORD 

;204 BUSY MASK 

204 PARAMETER REGISTER FULL AS 
;204 RESULT BYTE FULL MASK 


204 INITIALIZATION ROUTINE. RESETS 284 BOARD 
AND PERFORMS ALL OF THE NECESSARY INITIALIZATION 
OF THE 8257 AND 8271. 


INIT24 
WAITC 
WAITP 


A,OEH 


MMSET 
BASE+15 
A,1 
BASE+2 

A : 
BASE+2 
WAITC 
A,SPECFY 
BASE+9 
WAITP 

A, CHARS 
BASE+1 
WAITP 
A,STEP 
BASE+1 
WAITP 
A,SETTLE 
BASE+1 
WALTP 

A, LOAD 
BASE+1 
WAITC 
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me ~Oe =O TO TO NO TE NO TSH WE VO 


;ENTRY POINT 
;WILL BE USED EXTERNALLY 


‘ 


; DISABLE 
;ENABLE 5.5 INTERRUPT 


; 

;SET MASTER MODE FLIP FLOP 
;RESET INTERFACE 

;RESET 204 


=e =O “=O 


;WAIT TILL COMMAND WRITE VAL? 
;OUTPUT “SPECIFY" COMMAND 


v : 
;WAIT TILL PARAMETER WRITE VW? IL 
;SPECIFYING DRIVE CHARACTERISTIC 
OUTPUT STEP RATE 


OUTPUT HEAD SETTLE TIME 


OUTPUT HEAD LOAD TIME 
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PUBLIC 
INIT24 


3E35 
D386 
CDA1#0 C 
3E10 
0381 


CDA106 Coe 


3EFF 

D381 
CDA1WS oC 
3EFE 
D381 
CDA1W® Cc 
3EFF 

D381 
cp99ue@ 6C 
335 

D380 
CDA1¥® = =C 
3E18 

D381 
CDA1®@6  =C 
3EFF 

D381 
CDA1#® 6C 
3EFF 

D381 
CDAl#® = C 
3EFF 

D381 
CD9908 C 
3E69 

D388 


SYMBOLS 
C 88008 


WAITC : 


WAITP: 


WAITC C 6699 


APPENDIX B (Continued) 


A,SPECFY 
BASE+4 
WAITP 
A,BADTRI1 
BASE+1 
WAITP 
A,NOBAD 
BASE+1 © 
WAITP 
A,NOBAD 
BASE+1 
WAITP 
A,CTADDR 
BASE+1 
WAITC 
A,SPECFY 
BASE+ 
WAITP 
A,BADTR2 
BASEtlL 
WAITP 
A,NOBAD 
BASE+1 
WAITP 
A,NOBAD 
BASEt+l 
WAITP 
A,CTADDR 
BASE+1 


MMRSET 


A, OMAMOD 
BASE+8 


A, LOW (TCOUNT ) 


BASE+5 


A, HIGH (TCOUNT ) 


BASEt+5 


WAITC AND WAITP 


BASE+0 
BUSY 
WAITC 


BASE+0 
PARFUL 
WAITP 


WAITP C 6WA1 
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SPECIFY BAD TRACKS 
BAD TRACKS FOR SURFACE 1 
FIRST TRACK 


SECOND BAD TRACK 


SURFACE 2 
FIRST TRACK 


SECOND TRACK 


SEEK TO TRACK 6 


=e ™=8 te tO TOE “WS WS WE We VSO VO WH WH TE WS WE WOH WE WH ~WH WE WE WH WH WH WH WE WH BVO WH WH WH WH WO WO 


;GO TO SLEEP WHILE 294 DOES 
;ENABLE INTERRUPTS 

7; SLEEP 

; DISABLE 

;SET OMA MODE 


SET CONTROL REGISTER 


=e ~6 SO SB SO NO 


; RETURN 
ROUTINES 


;GET STATUS BYTE 
;BUSY? 

; YES, LOOP 
7;NO,RETORN 


;GET STATUS REGISTER 
;PARAMETER BUFFER FULL? 
;YES,LOOP 

7;NO, RETURN 
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CURRENT TRACK ADDRESS (NOT F “Ob 


CURRENT TRACK ADDRESS (NOT F OK 


IT 


APPENDIX B (Continued) 


EXTERNAL SYMBOLS 


USER SYMBOLS | ec = a 
BADTR1 A #010 #BADTR2 A 0018  ##BASE A 6080 BUSY A #080 CHARS A @00D . cTA 


INIT24 C 0600 LOAD A. 6869 MMRSET A @8E5. MMSET A @OE4 NOBAD A OFF _ AF 
SEEK A 8069 SETTLE A 0008 SPECFY A 8035 STEP A 08068 | TCOUNT A 4608 WAI 
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% OF MASTER CPU TIME AVAILABLE 


100 


80 


40 


20 


1/O CONTROLLER 


APPENDIX C (Continued) 


GRAPH 1 
MASTER CPU FREE TIME 
VS BAUD RATE 


BAUD RATE 
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DMA CONTROLLER AND INTELLIGENT SLAVE 4% 
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% OF BUS TIME AVAILABLE 


100 


95 


90 


85 


80 


APPENDIX C (Continued) 


GRAPH 2 
BUS FREE TIME 
VS BAUD RATE 


INTELLIGENT SLAVE 


1/0 CONTROLLER DMA CONTROLLER 


BAUD RATE 
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% OF SLAVE CPU TIME AVAILABLE 


‘APPENDIX C (Continued) 


_ GRAPH 3 _ 
SLAVE CPU FREE TIME 
VS'BAUD-RATE — 


100 


ey cae 


80 


60 


40 


i DMA CONTROLLER INTELLIGENT SLAVE 


BAUD RATE 


“ae 3 1-148 
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AVAILABLE CPU TIME 


1/0 CONTROLLER 


APPENDIX C (Continued) 


-GRAPH 4 
COMMUNICATIONS PROCESSOR FREE TIME 
‘VS BUS TRAFFIC 
@ 9600 BAUD FULL DUPLEX 


a - ri — = 30 : eon a a 


- % MAX BUS TRAFFIC 


INTELLIGENT SLAVE 


— DMACONTROLLER 


90 100 


AFN-01931A 


MAXIMUM ATTAINABLE BAUD RATE 


‘APPENDIX C (Continued) 


cr ¥S'BUS TRAFFIC, . 


INTELLIGENT SLAVE _ 


DMA CONTROLLER 


__./0. CONTROLLER — 


40 20 30 “40 80 60 “70 80 90 100 
 % MAX BUS TRAFFIC 
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APPENDIX D 


PL/M-~38 COMPILER SLAVE MAINLINE ROUTINE PAGE 1 


ISIS~II PL/M-86 V3.1 COMPILATION OF MODULE MAINLINE 
OBJECT MODULE PLACED IN :F1:MAINLN.OBJ 
COMPILER INVOKED BY: PLM8@ :f1:MAINLN.PLM PRINT (:F5:MAINLN.LST) PAGEWI OTH (78) 


Stitle('slave mainline routine') 
1 mainSline: 
DO; 


io | | | 
Mainline routine. Sets up stack$ptr, calls sSinit to init- 
lalize queues,initializes some of the hardware, sets uv the 
initial flag interrupt handlers, and then halts with interru 
- pts 
enabled allowing the rest of the system to operate totally 
in interrupt mode. 


*/ 
Snolist 
13 L initialShandler: PROCEDURE EXTERNAL; 
14 2 END initialShandler;: 
15 1 DECLARE 
commandSword LITERALLY ‘4lh', 
portSa$8155 LITERALLY 'ge9h', 
command$8155 LITERALLY 'Se8h', 
mask$8259 LITERALLY ‘'Je7h', 
icwl1$8259 LITERALLY 'Yebh', 
icw2$8259 LITERALLY ‘'We7h', 
ocw3$8259 LITERALLY ‘'gJeo6h', 
readSisr LITERALLY 'Obh', 


mask$word BYTE PUBLIC, 
portSaSvalue BYTE PUBLIC, 


stat BYTE, 

i BYTE; 
16 1 output (icw1$8259) =@f6h; 
17 ui output (icw2$38259) =@fh; 
18 1 output (mask$8 259) ,maskSword=6f fh; 
19 1 CALU sSinit; 

/* set up 8259 for ISR reads */ 

20 1 output (ocw3$8259)=readSisr; 
21 1 output (command$8155) =commandSword; 
22 1 Output (port$a$8155) ,portSa$value=8cUh; 
23 l DO i= TO 7; 
24 2 stat=setShandler(i,.initial$handler); 
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25) 


26 
27 
28 


29. 


APPENDIX D (Continued) 


2 END; 

l DO WHILE 1; 
2 HALT; 

2 END; 

1 END main$line; 


MODULE INFORMATION: 


CODE AREA SIZE = §94DH 
VARIABLE AREA SIZE = 60@4H 
-MAXIMOM STACK SIZE = @¥02H 


72 LINES READ 


@ PROGRAM ERROR (S) 
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APPENDIX D (Continued) 


P /M-~8@ COMPILER SLAVE APPLICATION LEVEL SIGNAL HANDLE PAGE 1 


ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE INITIALHANDLER 
OBJECT MODULE PLACED IN :F1:FINTRT.OBJ 
COMPILER INVOKED BY: PLM80 :F1:FINTRT.PLM PRINT (:F5:FINTRT.LST) PAGEWIDTH (78) 


Stitle('slave application level signal handler’ ) 
1 initialShandler: 
DO; 


/* 
Fields application level flag interrupts from the 
master. If the tyve=go$type the device attached to the queue 
specified is initialized with programming info sent into 
the queue by the master. If the type is dataSavailable the 
specified transmitter is enabled unless a control$S$s pause 
is in effect. 


a7 
Snolist 
32 1 DECLARE | . 

noSpause LITERALLY J ae 
goStype LITERALLY oF ae 
dataSavailable LITERALLY ‘2, 
enableSxmit LITERALLY Pa 2g 
reset LITERALLY "40h', 


timerSlScommandsport LITERALLY '‘édbh', 
timer$2ScommandSport LITERALLY '‘'ddfh', 
mask$8259 LITERALLY ‘SeT7h', 
maskSword BYTE EXTERNAL, 
mask (8) BYTE DATA( 
| ®fch, 

@fch, 

~E3h, 

Gf3h, 

Ocfh, 

Ocfh, 

63fh, 

O3fh), 
transmitterSstate (8) BYTE PUBLIC, 
type BYTE, 
token BYTE, 
i BYTE, 
progSinfo (5) BYTE, 
actual ADDRESS, 
ausartScommand$port (8) BYTE ia 
usartSstate (8) BYTE PUBLIC, 
lengthSpointer (8) ADDRESS PUBLIC, 
pointer (8) ADDRESS PUBLIC, 
charScount (8) BYTE PUBLIC, 
timerSloadSvort (8) BYTE DOATA ( 

Gd8h, 
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52 
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Ww 
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Od8h, - 
6d9h, 
O@d9h, 

“Odah, 
Odah, — 

-@deh, : 
Odch); 


an et ee end ers PROCEOURE woods) ecg 


DECLARE eéas BYTE; 


token=code AND fh; 
Re le Str teode, oe 


TE Ride gostype THEN 


_transmitter$state (token) = =no$pause; | 


pa reset ‘usart */. 


DO i=@ TO 3; 

CALL varout (usart$command$port (token) , 0); 
END; 
CALL varout (usart$command$port (token) ,reset) ; 


Reeds =get$iine (token, . progSinfo, 3) i 


/* eeaaean the devices ae 


‘CALL gavel Gas see eecnmands poret omen) orogsante Wise 
‘CALL varout (usart$command$port (token) , usartSstate (token) 


:=prog$info(1l)); 


/* open 


IF token <'7 THEN. = na 

CALL varout (timer $1conmandsport ,prog$info (2)) 
ELSE 

CALL varout(timer$2$command$port,prog$info(2)) ; 
CALL varout(timerSloadSport (token) ,prog$info (3)); 
CALL varout (timer$load$port (token) ,prog$info(4)) ; 


up the four input queues for data input a 


length$ pointer (token-1) =new$line (token-1) ; 


pointer (token-1) =next$space (token-1) ; 


END; 


ELSE 


charScount (token-1) =; 
output (mask$8259) , mask$word= ‘mask$word AND mask (token); 


LF (type= -dataavailable) AND "(transmitter $etate (token) =noS$pa 
use) THEN . 


DO; 


END; 


ieacesseaeeteonen) wives Pes seats ecKeni OR enableSxmit; 
CALL varout (usart$command$port(token) , usartSstate (token) 
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RETURN; 
63 2 _ END; | 
6&4 END initialShandler; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
154 LINES READ. 
@ PROGRAM ERROR(S) 


6182H 386D 
6¥43H 67D 
0004H 4D 


tou tt 
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APPENDIX D (Continued) 


ISIS-II PL/M-89 V3.1 COMPILATION OF MODULE INPUTHANDLER..- 
OBJECT MODULE PLACED IN :F1:INHDLR.OBJ 
COMPILER INVOKED BY: PLM80 :F1: INHDLR. PLM ee B5: INEDLR. ust) PAGEWIDTH (78) 


ened atweecor title('slave terminal input handler' me 
1 inputShandler: 


/* 


DO; 


544 resident interrupt service routine. After receiver : 
ready interrupt the 8259 In Service Register(ISR) is: 

read to determine which device is requesting service. 

The character is read in and placed in the appropriate 
queue. A check is made for break characters and appropriate 
action is taken if any are found. When an endline character 
is encountered the length byte is filled in ( it was left 
vacant when the line was started) and the xmit primitive is 
called to update the global queue pointer to permit access 
to the line. At this time the master is signalled to siqnify 
that a new line is available for processing. 


*/ 
Snolist 

34 1 DECLARE | 

| control$x. LITERALLY '18H', 
control$s LITERALLY '13H', 
control$qg LITERALLY ‘1la', 
rubout LITERALLY '7FH', 
escape LITERALLY ‘13H', 
CR LITERALLY ‘@DH', 
LE LITERALLY 'OAH', 
BS LITERALLY 'O8H', 
SP LITERALLY '26H', 
bell LITERALLY 'O7H', 
SUL LITERALLY "pointer (token) ', 
length$ptr LITERALLY ‘lengtnSpointer (token) ', 
count LITERALLY ‘charScount(token)', 
disableSxmit LITERALLY 'WFEH', 
enableS$xmit LITERALLY "O1H', 
noSpause LITERALLY ve ee 
pause LITERALLY iO 5 
lineSavailable LITERALLY ry 
ocw2$8259 LITERALLY ‘OE6H', 
ocw3$38259 LITERALLY ‘OE6H', 
EOI LITERALLY ‘20H'; 

35 l DECLARE 


valueSptr ADDRESS, 

value BASED valueSptr BYTE, 
lineSlength BASED valueSptr BYTE, 
dummy ADDRESS, 

ISR BYTE, 

token BYTE, 
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stat BYTE, 
newSptr ADDRESS; 


DECLARE 
pointer (8) ADDRESS EXTERNAL, 
lengthS$pointer (8) ADDRESS EXTERNAL, 
charScount (3) BYTE EXTERNAL, 
usartSstate (8) BYTE EXTERNAL, 
usartScommandSport (8) BYTE EXTERNAL, 
usartSdataSport (8) BYTE EXTERNAL, 
transmitterSstate (8) BYTE. EXTERNAL; 


index: PROCEDURE (value) BYTE; 


END; 


echo: 


DECLARE value BYTE; 


IF value=control$x THEN RETURN O- 
IF value=rubout THEN RETURN 1; 

IF value=controlSs THEN RETURN 2; 
IF value=controlS$q THEN RETURN. 3; 
IF value=escape THEN RETURN 4; 

IF value=CR THEN RETURN 5; 

RETURN 6; eG oc? 


PROCEDURE (token,buf$ptr,num$char) ADDRESS; 


DECLARE (buf$ptr,num$char,actual). ADDRESS, 
token BYTE; 


actual=send$line(token,bufSptr,num$char) ; 


usartSstate (token) =usartSstate(token) OR enableSxmit; 


CALL ee na on rane usar teetere (hOKen) 2) 


RETURN actual;: 
END; 


deleteSline: “nae 


END; 


lengthSptr=newSline (token) ; 

ptr= ieee eRace ecko ny: 

count=¢d; 

dummy= sohereokentl 2 #',CR,LF) ,3);3 
RETURN; 


endSline: PROCEDURE; 


valueSptr=lengthSptr;. 
lineSlength=count; 


-ptr=nextSspace(token) ; 


stat=xmit (token) ; 
lengthSptr=newSline(token); . 
ptr=nextSspace(token); 

count=@; 

stat=set$s$interrupt (token, pine aver rapte): 
RETURN; SS 


END; 
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78 1 inShdlr: PROCEDURE. INTERRUPT. Qo PUBLIC; 
79 2 ISR=input (ocw3$8259) ; | 

80 2 token=6; 

81 2 again: 


TSR=sh1 (ISR, 2D: 


82 2 IF NOT carry THEN 
83 2 DO;... - aa 3 
84 3 IF token= 0 THEN RETURN; /* no. bits set */ 
ELSE 
86 3 DO; i a 
87 4 token=token-2; 
838 4 GOTO again; 
89 4 END; ag 
98 3 : END: | - 
91. 2 valueSptr=ptr; © | 
92 2 value= var inp (usart$data$port (token) ) AND: w7£h; 
93 2 DO CASE index (value); 
/* case 6; control$x; delete line */ 
94. 3 DO; 
95 4 CALL delete$line; 
96 4 END; 
/* case ay eubouteeelere ar i 
ae Big! DO; | 
98 4 newS$ptr= shee eeuace tesa: 
99 4 IF newSptr=lengthSptr THEN 
199 4 dummy = Rey CORSE eee Le 
ELSE 
1¢@1 4 DO; 
162 5 dummy= =echo(tokent1,. (BS, SP,8S),3);3 
103 5 ptr=newSptr; 
164 5 count=count-1; 
165 5: END; 7% — 
106 4 END; 
/* case 2; control$s; pause output */ 
107.3 DO; _ | | 
188 4 usart$Sstate(tokentl)= =usart$state(token+1) AND disabl 
7 - eSxmit; 
109 4 CALL varout (usart$conmand$port (tokentl) usart$state | 
- tokentl)); 
110 4 transmitter $state (tokent1): 7Oeuee 
lil 4 END; | 
 J*® case 3; control$gd; resume Sccode */ 
LEQ. 3 : DO; 
113 4 usart$state (token+1) = cqwapesseatedtonentd) OR enable$ 
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- xmit; 
114 4 CALL varout(usart$commandSport (tokent+l) ,usartSstate ( 
- tokent+l1)); 
115 4 transmitterSstate (tokentl) =noSpause; 
116 4 END; 
/* case 4; escape; terminate line */ 
117 3 DO; 
118 4 dummy=echo (tokentl,. ('#',CR,LF) ,3); 
119 4 value=CR; 
126 4 count=counttl; 
121 4 CALL endSline; 
122 4 END; 
/* case 5; carriage return: terminate line */ 
123 3 DO; | | 
124 4 : dummy=echo(tokentl,.(CR,LF) , 2); 
125 4 count=counttl; 
126 4 ptr= =next$space (token) ; 
127 4 value$ptr= ptr; 
128 4 value=LF; 
129 4 count=count+]; 
136 4 CALL endSline; 
131 4 END; 
/* case 6; non-break character; stuff into queue */ 
132 3 DO; | : | — 
133 4 dummy=echo(tokentl,ptr,1); 
134 4 ptr=nextSspace (token) ; 
135 4 IF ptr=% THEN CALL delete$line; /* full buffer */ 
137 4 ELSE count=counttl; 
138 4 END; 
139 3 END; /* of do case */ 
140 2 Output (0cw35$8259) =EOI; 
141 2 RETURN; 
142 2 END; 
143 1 END input$handler; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
255 LINES READ 
@ PROGRAM ERROR (S) 


0398H 920D 
O011H 17D 
OV10H 16D 
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APPENDIX D (Continued) 


SLAVE CHARACTER OUTPUT HANDLER set PAGE 1 


ISIS-II PL/M-8%8 V3.1 COMPILATION OF MODULE OUTPUTHANDLER | 
OBJECT MODULE PLACED IN :F1:OUTHLR.OBJ | 
COMPILER INVOKED BY: PLM8#@ :F1:OUTHLR.PLM PRINT (:F5: OUTHLR. LST) PAGEWIDTH (78) 


11 


12 


13 


Snointvector title('slave character output handler’) 
outputShandler: | 


/* 


DO; 


544 resident interrupt service routine. After transmitter 
ready interrupt, 8259 In Service Register(ISR) is read to 
determine which device is requesting service. A character 
is requested from the appropriate queue and, if available, 
is sent to the usart. If the gueue is empty the transmitter 
is disabled pending a signal from the master when more 
characters are put into the queue. 


*/ 
Snolist 
DECLARE . 
ocw2$8259 LITERALLY 'OEOH', 
ocw3$8259 LITERALLY 'PEOH', 
disableSxmit. LITERALLY 'OFER', 
true LITERALLY 'OFFH', 
false LITERALLY 'QUH', / 
EOL LITERALLY ‘OAOH'; 
DECLARE 
ISR BYTE, 


token BYTE, 
actual ADDRESS, 
value BYTE; 


DECLARE 
uSartSstate (8) BYTE EXTERNAL, | 
usart$command$port (8) BYTE PUBLIC DATA ( 
QD1H, 
@D1H, 
QD3H, 
QD3H, 
QD5H, 
QD5H, 
OD7H, 
@D7A), | - . 
uSartSdataSport (8) BYTE PUBLIC DATA( 
QDOH, 
QDOH, 
®D2H, 
QD2H, 
Qd4H, 
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QD4H, 
QD6H, 
OD6H); 


outShlr: PROCEDURE INTERRUPT 1 PUBLIC; 


/* get active level number and use it to determine queue$token * 


ISR=input (ocw3$8259) ; 
tok2n=7; 


again: 
ISR=shl (ISR,1); 
If NOT carry THEN 
DO; | 
IF token=l1 THEN RETURN; /* no bits in ISR set */ 
ELSE 
DO; 
token=token-2; 
ISR=shl(ISR,1); 
GOTO again; 
END; 
END; 


actual=getSline(token,.value,1); 
IF actual=@ THEN 
DO; /* empty queue. Disable transmitter */ 
usartSstate (token) =usart$state(token) AND disabl 
eSxmit; | 
CALL varout (usart$commandSport (token) ,usartS$stat 
e (token) ); 
END; 
ELSE 
CALL varout(usSart$dataSport (token) ,value); 
output (ocw3$8259) =EOI; 
RETURN; 
SND; 
END outputShandler; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
1@2 LINES READ 
0 PROGRAM ERROR (S) 


= Q¥A4H 164D 
= @005H 5D 
= @00CH 12D 
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PL/M-88 COMPILER RMX/80-544 INITIALIZATION sic PAGE 1 


ISIS-II PL/M-89 V3.1 COMPILATION OF MODULE INITS44 | 
OBJECT MODULE PLACED IN :Fl]:INIT54.0Bd : . 
COMPILER INVOKED BY: PLM8Q@ _ iP: Intt54. PLM PRINT (: F5: INITS4. meet, PAGEWIDTH (78) 


Stitle('rmx/84-544 initialization ‘task')” 
1 init$544: 
DO; 


/* one 
Task code for 544 driver initialization ‘task. Info 
from application supplied memory allocation block 
is accessed to set up. queues and transfer device programming 
“- info to the slave. board(s) and ‘create the reguired 
service handler tasks. 
*/ 


Snolist 


56 1 input$driver: | PROCEDURE EXTERNAL; 
57 2 END inputSdriver; 


58 1 outputSdriver: PROCEDURE EXTERNAL; 
59 2 END. output $driver;. | 


“6@ 1° signal: PROCEDURE Memaceaa te: 
Ol 2 END signal; 


62 a DECLARE 7 
Stack$size LITERALLY ‘256°, 


63 1 DECLARE + 
ptr ADDRESS, 
initStable BASED ptr STRUCTURE ( 
baseSadr ADDRESS 
queueStoken BYTE, 
progSinfo (5) BYTE), 
i BYTE, 
overflow ADDRESS, 
queueSinitStable (1) STRUCTURE ( 
baseSadr ADDRESS,’ 
queueSsize (8) ADDRESS). EXTERNAL, 
initialization$table (1) BYTE EXTERNAL, 
stat BYTE, 
numSdevices BYTE EXTERNAL, 
numSboards BYTE EXTERNAL, 
serviceSexchangeStable (1) ADDRESS EXTERNAL, 
SignalSexchangeStable (1) ADDRESS EXTERNAL, 
serviceSexchanges (1) BYTE EXTERNAL, 
SignalSexchanges (1) BYTE EXTERNAL, 
\ taskSdescriptors (1) BYTE EXTERNAL, 
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64 


65 
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stacks (1) BYTE EXTERNAL, 

infoSblock (1) STRUCTURE ( 
baseSadr ADDRESS, 
queueStoken BYTE, 
index BYTE) EXTERNAL, 


rgactv ADDRESS EXTERNAL; 
DECLARE 
rom$input$std peeve ger tecee reiuecr DATA ( 
‘input ', 


.inputSdriver, 
, /*® stack will be assigned individually */ 
eer 
re 
fk tba */ 
5}, T* tia */- 
rom$output$std static$task$descr iptor DATA ( 
‘outout', 
output$driver,. 
0, 
stacksize, 
201, 
0, 
0), , 
inputShdirSstd staticS$taskS$descriptor, 
Cue PEE gn ve sc BEC tee trehodeec bt per 


init$xch:. | PROCEDURE. (xchSptr).;_ 
/* initializes expanded interrupt exchanges */ 


DECLARE xch$ptr ADDRESS, 
xch BASED xchSptr intSexchangeSdescriptor; 


xch.link=.xch.link; 
xch.type=intStype; 
xch.length=5; 
RETURN; 

END; 


init$54: PROCEDURE PUBLIC; 


DO i=# TO numSboards-1l1; 
CALL mSinit(.queuvueSinitStable(i)); 
END; 


CALL move (size (rom$input$std) ,.rom$input$std,.input$hdlir$std 
)3 

CALL move (size (rom$output$std) ,. rom$output$std, output $hdlr$ 
std); 

ptr=.initializationStable; 


DO i=8 TO num$devices*2 BY 2; 
/* send pogramming info to slave */ 
overflow=sendSline(initStable.baseSadr,init$table.queue$ 
token,.initStable.progSinfo,5); 
stat=set$mSinterrupt (initStable.baseSadr,initStable.queu 
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82 
83 


84 
85 
86 


87 


83 


89 
9d 
91 
92 


93 
94 
95 
96 
97 


98° 


99 
1080 
161 
192 


163 
104 
105 
196 
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-eStoken,goStype) 7 are 


/* create service and. signal ‘exchanges */ 


st1@*i); 


WW Ww 


215 *4) 9. 


W 


CALL rgexch (serviceSexchange$table (i) :=. serviceSexchange 


a 


‘CALL. init$xch (; signalSexchangest+15*i); 
CALL init$xch(.signalSexchangest+15*(it+1l)); 


CALL rqcxch (servicesexchangestable (i+) =,serviceSexchan 
eee ee oe 


CALL rqexch (signalSexchangeStable (i) :=. signal Sexchangest 


CALL rqcxch (signal$exchange$table (itl) :=. signalSexchange 


s+15*(it+1)); 


info$block (i). baseSadr; 


-..infoS$block(it+l).baseSadr=initStable. pheessare 


WWW WW WWW W 


WW WW 


END; 


NO BN NN bh 


END; /* 


_ 


MODULE INFORMATION: 


CODE AREA SIZE... 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE. 


285 LINES READ 


infoS$block(i).queueStoken=initStable.queueStoken-1; 
info$block (itl). queue$token= anitetabie: queue$token; 
infoSblock(i).index=i; 

infoSblock (itl) .index=i+l; 


inputShdlirSstd.sp=. Ee ee rr Te 
OutputShdlrSstd.sp=. stacks+stack$size* (i+l); 


 inputShdlrS$std.exchangeSaddress=. infoSblock (i); 
~-- output$ShdirSstd.exchangeSaddress=.info$block (itl); 

-inputShdlrSstd.task$ptr=.task$descriptors+20*i; 
ouepubebdiensede task$ptr=. task$descriptors+20* (itl); 


CALL ractsk (. input$hdlr$st4d) ; 


CALL ae poMepEe ene tence); 


 ptr=otrt8; 


CALL rgsetv(.Ssignal,2); 
CALL rgelvl(2); 
CALL rqsusp(rqactv); 


of task */ 


END init$544; 


92C3H - -707D_ 
OU2AH 42D 
OOOOH. -° 6D. 


how ou 


6 PROGRAM ERROR (S) 
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P /M-80 COMPILER RMX/80-544 INITIALIZATION MODULE AND PAGE 1 


ISIS-II PL/M-80 V3.1 COMPILATION OF MODULE INITMODULE 
OBJECT MODULE PLACED IN :F1:MAB.OBJ 
COMPILER INVOKED BY: PLM8@ :F1:MAB.PLM PRINT (:F5:MAB.LST) PAGEWIDTH (78) 


Stitle('rmx/8¥-544 initialization module and memory allocation b 


= lock") 
1 initSmodule: 
DO; 
lee 7 
Initialization tables created and allocation of memory for 5 
- 44 
handler done here. 
af 
2 1 DECLARE ; oe 
numperSof$devices LITERALLY TAS 
baudSrateScountsl . LITERALLY ‘32% 
baud$SrateScountsh LITERALLY 'O6', 
usartSmode LITERALLY '4eh', 
usart$cmd LITERALLY '27h', 
ctrséSmode LITERALLY ‘'36h', 
ctr$SlSmode LITERALLY  '76h', 
ctr$2Smode LITERALLY 'Oboh', 
ctr$3Smode LITERALLY 36h" '¢ 


num$Sdevices BYTE PUBLIC DATA(numberSofS$devices-l), 
numSboards BYTE PUBLIC DATA(1), 
serviceSexchangeStable (8) ADDRESS PUBLIC, 
SignalSexchangeStable (8) ADDRESS PUBLIC, 
SignalStyve (8) BYTE PUBLIC, 
serviceSexchandges (88) BYTE PUBLIC, 
SignalSexchanges (128) BYTE PUS8LIC, 
taskSdescriptors (168) BYTE PUBLIC, 
stacks (2448) BYTE PUBLIC, 
infoSblock (32) BYTE PUS8LIC, 
JueueSinitStable (1) erROeruee 
baseSadr ADDRESS, = 
queueSsize (8) ADDRESS) PUBLIC DATA( 
Geb 4Oh, 
256, 
1765, 
256, 
1765, 
256, 
1765, 
256, 
1765), 
baseStable (1) ADDRESS PUBLIC DATA ( 
Ve UBh), 
initializationStable (numberSofSdevices) STRUCTURE ( 
baseSadr ADDRESS, 
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3 1 END init$module; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
79 LINES READ 


Y PROGRAM ERROR(S) 


APPENDIX D (Continued) 


gqueueStoken BYTE, | 
progSinfo (5) BYTE) PUBLIC DATA ( 


Ged 0h, 


usart$mode, 


- usartS$emd, 


ctr$@$Smode, 
baudSrateScountSl, 
baudSrate$count$h, 


GeGUGh, 

3, 

usartSmode, 
usartscmd, 
ctr$l$mode, 
baudSrateScount$l, 
baudSrateScount$h, 


VeWUOh, 

5, 

usartSmode, 
usartSemd, | 
ctrS$2Smode, 
baudSrateScountsSl, 
paper be ree Couns 


de0 20h, 

Rig ) 

usartSmode, 
usartScmd, 
ctr$3$mode, 
baudSrateScountsl, 
baudSrateScountSh) ; 


O836H . -54D.. 


O9BOH 2480D 


O000H OD 
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P /M-8@ COMPILER SLAVE->MASTER INTERROPT HANDLER  — | PAGE 1 


ISIS-II PL/M-8 V3.1 COMPILATION OF MODULE SIGNALHANDLER 


OBJECT 


MODULE PLACED IN :F1:SIGNAL.OBJ 


COMPILER INVOKED BY: PLM8#@ :F1:SIGNAL.PLM PRINT (:F5:SIGNAL.LST) PAGEWIDTH(78) 


26 


27 


37 
38 


GJ GW DO Dd 


Snointvector title('slave->master interrupt handler’) 


signalShandler: 
DO; 
ys | 
Fields all slave->master signals(interrupts) and calls rqisn 
d 
with the proper signal exchange address. 
oy 
Snolist 
DECLARE 
i BYTE, 
ptr ADDRESS, 


(flag BASED ptr) BYTE, 

numSboards BYTE EXTERNAL, 

numSdevices BYTE EXTERNAL, 

SignalStype (1) BYTE EXTERNAL, 

index BYTE, 

token BYTE, 

signalSexchangeS$table (1) ADDRESS EXTERNAL, 
baseStable (1) ADDRESS EXTERNAL; 


Signal: PROCEDURE INTERRUPT 2 PUBLIC; 
/* poll slave boards and find one generating interrupt */ 
l=; 
next: 
ptr=baseStable(i)+1; 
IF flag=@ THEN 
DO; 
i=it+l; 
IF i > numSboards THEN RETURN; /* erroneous signal * 


ELSE GOTO next; 
END; 


/* get queue token and use it to index into signal exchange tabl 


e */ 


token=(flag AND wéfh); 
index=4*it+token; 


/* if index is out of range don't attempt the isend */ 
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39 «2 IF index <= numSdevices THEN ~ 
40 2 DO; 
4) 3 CALL eqrendtsignalvexchanges table index) ): 
42 3 signal seype (index) =shr (flag,4); 
433 | END; 

ELSE 
44 2 CALL rgendi; 

t Zero flag to acknowledge interrupt */ 

45 2 flag=90; 
46 2 RETURN; 
47 2 END; 
48 1 END efencsianaters 


_ MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
118 LINES READ 
@ PROGRAM ERROR (S) 


008BH 139D 
0005H 5D 
OOBAH 16D 
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P /M-8@ COMPILER RMX/80-544 INPUT SERVICE HANDLER PAGE 1 


ISIS-II PL/M-88 V3.1 COMPILATION OF MODULE INPUTDRIVER 
OBJECT MODULE PLACED IN :Fl:INPUT.OBJ 
COMPILER INVOKED BY: PLM8V :Fl:INPUT.PLM PRINT(:F5:INPUT.LST) PAGEWIDTH (78) 


Stitle('rmx/8¥8-544 input service handler') 
1 inputSdriver: 
DO; 


/* 
Master resident task code. Monitors service exchange 
and fills input requests by retrieving characters from 
the proper gueue(boardSbase and device info is passed 
via default exchange field). By definition the first byte 
of a line of input contains the length of that line. 
This figure is used to retrieve the exact number of characte 


- rs 
available in a given line. 
e/. 
Snolist 
27 1 DECLARE 
rqactv ADDRESS EXTERNAL, 
td BASED rgactv task$S$descriptor, 
serviceSexchangeStable (1) ADDRESS EXTERNAL, 
SignalSexchangeStable (1) ADDRESS EXTERNAL; 
28 1 inputSdriver: PROCEDURE REENTRANT PUBLIC; 
29 2 DECLARE 


serviceSexchange ADDRESS, 
boardSbase ADDRESS, 
queueStoken BYTE, 
SsignalSexchange ADDRESS, 


msg$ptr ADORESS, 
msg BASED msgSptr thSmsg, 
actual ADDRESS, 
dummy ADDRESS, 


infoSblock$ptr ADDRESS, 

infoSblock BASED infoSblockSptr STRUCTURE ( 
baseSadr ADDRESS, 
queuestoken BYTE, 
index BYTE), 

num$char BYTE, 

stat BYTE; 


/* get info out of default field */ 


30 2 infoSblockSptr=td.exchangeSaddress; /* default exchange fiel 
ss d x / 
31 2 serviceSexchange=serviceSexchangeStable(info$block.index);_ 
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Pas eee? bo ardSbase=info$block.baseSadr;. 

33 2 queueStoken=infoS$block.queueStoken; 

34 2 signal$exchange= Fo Spee me nancy ete nee EL oeks index); 

35 2 DO forever; 7 | 
/* wait for request message */ 

36 3 msg$ptr=rqwait (serviceSexchange,4@) ; 

37 3 retry: | | 7 . 
/* try to gat line count out of queue */ 

actual= sees ine (boa dspace queues tokensanunsenacs 1); 

e if unsuccessful wait Or. -eagnas and ey again */ 

38 3 IF actual= 0 THEN 

3903: 00; | 

1 rr Bums rqwa it (signal$exchange, in 

41 4 . GOTO retry; 

“AQ 4& END; 

/* if all okay get line */ 

43 3 actual= get$line (board$base,queue$token, msg. bufferSadr,nu 

- m$ char) ; 

44 3 msg.actual=actual; 

45 3 msg.status=0; 

46 3 CALL rqsend (msg. respSex msg$ptr) + 

47 3 END; a of do" forever af 

48 2 END ; y* of task: &/ 

49 1 END inputS$driver; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
171 LINES READ 
@ PROGRAM ERROR (S) 


012CH 309D 
O600H 0D 
Q817H ~ 23D 
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P /M~88 COMPILER RMX/86-544 OUTPUT SERVICE HANDLER PAGE 1 


ISIS-II PL/M-88 V3.1 COMPILATION OF MODULE OUTPUTDRIVER 
OBJECT MODULE PLACED IN :F1:OUTPUT.OBJ : 
COMPILER INVOKED BY: PLM80 :F1:OUTPUT.PLM PRINT(:F5:OUTPUT.LST) PAGEWIOTH(78) 


Stitle('rmx/80-544 output service handler') 
1 outputSdriver: 
DO; 


/* 
Master resident task code. Monitors service exchange and 
fills output requests by stuffing characters into the approp 
- riate 
queue. If insufficient room is available the task waits 
for 1 second and retries up to 168 times after which it 
signals a time out error. If the transmission completes 
successfully the slave is signalled to indicate that data is 


available. 


*/ 
Snolist 
39 1 DECLARE 
dataSavailable LITERALLY 2 
timeSout LITERALLY oe ae 
42 1 DECLARE 
rgactv ADDRESS EXTERNAL, 
(td BASED rgqactv) task$descriptor, 
serviceSexchangeStable (1) ADDRESS EXTERNAL, 
SignalSexchangeStable (1) ADDRESS EXTERNAL; 
41 1 output$driver: PROCEDURE REENTRANT PUBLIC; 
42 2 DECLARE 
serviceSexchange ADDRESS, 
signalSexchange ADDRESS, 
baseSadr . ADDRESS, 
queueStoken BYTE, 
msg$ptr > ADDRESS, 
msg BASED msg$ptr th$msg, 
tries$left — BYTE, ake 
overflow . ADDRESS, 
dummy ADDRESS, 
stat BYTE, 
infoSblockSptr ADDRESS, 


infoSblock BASED info$blockSptr STRUCTURE ( 
baseSadr ADDRESS, 
queueStoken BYTE, 
index BYTE); 
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/* initialize */i.. 


infoSblockSptr=td.exchangeSaddress; 


43 2 
44 2 serviceSexchange=serviceSexchangeStable(info$block.index); — 
45 2 signalSexchange= signal $exchange$table(info$block. Gea T io 
46.025 os: bas2Sadr=info$block.baseSadr; . eG are 
47 2 queueStoken=infoSblock. gqueue$token; 
43 2 DO POrEVEE: 
/*® wait or pedueee: message +“ 
49 3 msg$ptr=rqwait (serviceSexchange,J); 
58 3 tries$left=100; 
oe a su R@Erys 
Ae! ite Gp, 4 ea  RVeeE cue onde 1 ine (basesaaryqueucstoKen: msg. bufferSadr,m 
- pe sg. count) ; 7 3 
52. 3 a -If overflow <> Y THEN 
53. »3 | DO;. |: 
54 .4 | : _. dummy= rGuste(stanalsoxenange, 20) 5 
~55...4 triesS$left=triesSleft-1l; |. 
56 4 IF tries$left > #@ THEN GOTO retry: 
ELSE ae 

58 4 DO; 
59 ° msg.status=timeSout; 
60 5 msg.actual=U; | 
61 5 GOTO quit; ad 
62 5 END; nad ie 
63 4 END; 
64 3 msg. Seabee Q; : 
65 3 stat= set Sm§ interrupt (base$adr ,queue$token, dataSavailable 

= 3 a 
66 3 msg.actual=msg.count; — 
67 3 oe: 

| CALL rqsend (msg. respSex, msgSptr) 

68 3 “END; ft of do forever */ . oe 
69 2 END; /* of task */. 
76 1 END output$driver; 


MODULE INFORMATION: 


CODE AREA SIZE. 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
198 LINES READ 
®@ PROGRAM ERROR(S) 


@159H  345D 
0000H OD. , 
00198 2, 28De: 
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ISIS-II 8080/8985 MACRO 


APPENDIX D (Continued) 


:Fl: CFG544.M80 PRINT(:F4:CPG544.L5T) PAGEWIDTH(78) MACROFILE 


LOC OBJ 


UZHG B380G 


OOKD 
BOB 


PUBLIC SYMBOLS 


ROCRTB C 6826 


EXTERNAL SYMBOLS 


INIT54 E 0608 


USER SYMBOLS 


CRTAB 
INTXCH 
NTASK 
RQRATE 
XCHADR 


+ 


+ 
A 
C 
+ 


G6 OOU 
0800 
0002 
6208 
OWO2 


RQRATE 


LINECH 


GENTD 
ITT 
PUBXCH 
STD 


ASSEMBLER, V3.4 CFS544 PAGE 1 
SOURCE STATEMENT 
NAME CFG544 
CSEG 
PUBLIC RQRATE 
RORATE: DW 8 
SNOLIST 
SLIST 
SNOGEN 
NTASK SET 0 
NEXCH SET ) 
; 
; BUILD THE INITIAL TASK TABLE 
7 \ THIS TASK IS NECESSARY FOR THE 544 HANDLE 
R 
$o aae----- / IT CREATES EVERYTHING ELSE IT NEEDS. 
STD INIT54,200,1,0 
STD LINECH,64,130,90 


Ve) 


ODO 


0000 
0OV2 
6007 
W809 


ALLOCATE TASK DESCRIPTORS 


GENTO 


BUILD INITIAL EXCHANGE TABLE 


XCHADR- RE 


BUILD CREATE TABLE 


CRTAB 
END 


RESPEX E 


IeT c 
LINECH & 
RESPEX E 
TDBASE D 
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SPEX 


UOOO 


0824 
O0d0 
ey 
0168 


INIT54 E O008 
NEXCH A 6061 
ROQCRTB C 6026 
XCH + 9085 
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INTRODUCTION 


Intel’s single board computers and the MULTIBUS™ 
system bus have become de facto industry standards in 
the microcomputer board market. The speed and capa- 
bility of the bus coupled with the functionality and per- 
formance of the boards have been used to solve a large 
number of problems. iSBC products are in applications 
ranging from simple single board relay replacement to 
sophisticated multi-board business systems supporting 
large hard disk files. However, even with the range of 
functionality provided by standard iSBCs and expan- 
sion boards, designers have felt the need to design 
custom MULTIBUS-compatible boards to fit their ap- 
plication. Until the introduction of the iSBX concept, 
these custom boards had to be implemented using a 
separate MULTIBUS form factor board. 


Intel has recently introduced a new line of board prod- 
ucts anu 2 new bus which are destined to become 
another industry standard because of the niche they fill. 
The new iSBX MULTIMODULE boards are designed 
to extend the functional capabilities of single board 
computers at a much lower cost than previously possi- 
ble. iSBX MULTIMODULE boards are supported by a 
new bus — the iSBX bus, which allows the MULTI- 
MODULE boards to be added directly to the on-board 
microprocessor bus.. iSBX MULTIMODULE boards 
are from 10 to 20 square inches in size, therefore permit- 
ting small modular. increments to a single board com- 
puter’s capabilities. 


System designers now have the capabilities of using 
either standard iSBCs: or iSBX MULTIMODULE 
boards, or designing custom MULTIBUS compatible or 
iSBX MULTIMODULE boards. Cost-effective solu- 
tions are easily realized because of this added flexibility. 


This application note discusses the iSBX MULTI- 
MODULE concept, currently available MULTIMOD- 
ULE boards and the iSBCs which support these boards. 
The iSBX bus interface specifications are discussed 
next, followed by consideration for designing custom 
iSBX MULTIMODULE boards. A specific design ex- 
ample using an Intel® 8279 Programmable Keyboard/ 
Display Controller is presented. 


The bijective of the note is to introduce the reader to 
the iSBX MULTIMODULE concept for expanding 
iSBC functionality and to illustrate how a designer can 
effectively use this concept with either standard or 
custom iSBX boards. 


References to further documentation on the iSBX bus, 
specific iSBX MULTIMODULE boards and iSBC host 
boards currently available may be found in the Related 
Intel Publications section in the front overleaf. of this 
application note. 


iSBX™ MULTIMODULE™ BOARD 
CONCEPT 


The iSBX MULTIMODULE board concept was devel- 
oped to provide the users of Intel single board com- 
puters (ISBCs) with a convenient method to increment- 
ally expand the I/O or the computing capabilities of a 
single board computer. This expansion is done through 
the use of a new interface called the iSBX bus interface. 
This interface gives the user the capability of adding I/O 
mapped functions directly onto the microprocessor bus 
via plug-in modules that connect to the iSBC board by 
means of a special iSBX connector. With the use of this 
new bus interface, it is now possible to expand or add 
new features to your iSBC system without incurring 
large costs and long engineering development times. 


There are a number of unique advantages to using the 
iSBX bus interface for system expansion rather than 
adding a separate expansion board to your system. 
First, when expansion is required, the user needs only to 
buy what is required for the application. Second, it is 
now possible to return to one board solutions for small 
systems. One board solutions eliminate the need for ex- 
pensive backplanes and cardcages. Next, the iSBX inter- 
face connects directly to the microprocessor or. local 
bus, as opposed to interfacing to the MULTIBUS sys- 
tem bus, therefore I/O expansion does not require 
system bus cycles. To the CPU, the iSBX board looks 
like any other on-board I/O device (Figure 1). Address 
decode logic exists on the iSBC host board for each 
iSBX connector on the host board. 


iSBC™ 
SINGLE BOARD 
COMPUTER 


CPU BUS 


(PARALLEL 
fe) 


SERIAL 
V0 


Figure 1. iSBC™ Host Board Block Diagram 


Third, if there is no isBC or MULTIBUS compatible 
expansion board available to fit the needs of your appli- 
cation or if the expansion boards available offer more 
capability than required, then it is possible to design a 
custom iSBX MULTIMODULE board. Custom iSBX 
boards offer several advantages over custom MULTI- 
BUS boards: they require less board real estate (10 or 20 
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square inches versus 81 square inches) and less engineer- 
ing design time; consequently, they cost considerably 
less to implement. Additional capability is therefore 
achieved with maximum productivity. 


Currently available Intel iSBX ‘MULTIMODULE 
Boards include: 


1) iSBX 350 Parallel 1/0. MULTIMODULE board 
which contains 24: programmable I/O lines with 
sockets for line drivers and terminators. 

2) iSBX 351 Serial 1/0 MULTIMODULE board 

- containing one RS232 or RS449/422 program- 
mable synchronous/asynchronous communica- - 
tions channel and two timers. 

3) iSBX 331 Fixed/Floating Point Math MULTI- | 
MODULE board which permits fixed or floating 
point mathematics via the Intel 8231 device. 

4) iSBX 332 Floating Point Math MULTIMODULE 
board which permits floating point mathematics. | 
using the Inteland proposed IEEE floating point . 
standards via an Intel 8232 device.. 


With these iSBX MULTIMODULE boards and other 


soon-to-be-announced boards, the capability now exists 


to economically tailor a single board computer to the 
application using off-the- shelf pega: 


iSBX™ MULTIMODULE™ SYSTEM 
INTERFACE 7 


This section begins by decctibine the baie. eciein ele- 
ments used in an iSBX MULTIMODULE interface con- 
figuration and then defines the interface signals used for 
the communication between these elements. The specifi- 


cations contained in this application note are included. 


for descriptive and tutorial purposes only. The ultimate - 


source for this information is the iSBX Bus Specifica-. 


tion which is referenced in the front overleaf of this 
note. 


Host Boards 


The host board provides an electrical and mechanical in- 
terface for the iSBX expansion module. The host board 
is the master of the communications between the host 
and iSBX board, it controls the address and command 
signals. 


The second iSBC board available. supporting. ISBX 
boards is the iSBC 80/24 Single Board Computer. The 
80/24 board, which supports two iSBX’ MULT IMOD- 
ULE boards, contains an 8085A-2 CPU operationg at 
4.8 or 2.4 MHz, 4K bytes of RAM, sockets for up to’ 
32K bytes of EPROM, 48 parallel I/O lines, a program- 
mable synchronous/asynchronous | communications in- 
terface, three programmable interval timers and a pro- 
grammable interrupt controller. Further RAM expan- 
sion on the 80/24 board is accomplished by the addition 
of an iSBC 301 4K byte RAM MULTIMODULE board 
which expands the RAM by an additional 4K bytes for'a. 
total of 8K bytes. The iSBC 301 MULTIMODULE 
board is not iSBX bus compatible; it is attached via pins 
and sockets i in the RAM section oO the nos board. 


iSBX™ MULTIMODULE™ Boards 

The iSBX MULTIMODULE boards communicate with 
the host boards via the iSBX bus interface. These iSBX 
boards are I/O mapped through pre-defined select lines 
to specific port addresses. The iSBX bus ‘currently 
defines an 8-bit data‘path compatible with both 8 and’ 
16-bit’ future iSBC ‘host boards. Examples of possible’ 
iSBX expansion boards include a floppy disk controller, 

a cassette interface, -analog- to- digital converter or 
digital-to- analog converter boards, an interface to ‘the 
IEEE 488 Bus and a video p eraphies ey untertete 
board. -: 


There are two standard sizes of iSBX boards: a single- 
wide board measuring 7.24 by 9.40 cm (2.85 by 3.70 
inches) and. a double-wide board measuring 7.24 by. 
19.05 cm: (2.85. by 7.50. inches). ‘The iSBX MULTI- 
MODULE. boards mount onto..any microcomputer: 
board containing an iSBX : connector. and: mounting 


hole. The iSBX boards physically plug into. the iSBX 


A new generation of iSBX bus compatible host boards 


are evolving. The first board available from Intel is the 
iSBC 80/10B Single Board Computer. The 80/10B con- 
tains an 8080A CPU operating at 2 MHz, 1K bytes of 
RAM with sockets available for expansion to 4K bytes 
of RAM, sockets for up to 16K bytes of EPROM, 24 
parallel 1/O lines, a programmable synchronous/asyn- 
chronous communications interface and a fixed 1.04 


msec timer. The 80/10B has one iSBX connector, per-. 


mitting the use of an iSBX MULTIMODULE board. 
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connector on the host board and are secured with a 
nylon stand-off and screws. The mounting ‘hardware 
supplied as part of the iSBX board ese: - wo 


1) One nylon spacer, 1/2" threaded — 
2) Two nylon Screws, 1/4 : 6- 32 
3). One 36- -pin connector, ‘factory-installed onto the 


iSBX module. (These may also be. purchased from | 
Intel. ) 


The interconnection ee the hod sonia aaa iSBX 
board, as well as the mounting, clearances, nay be seen 
in PIEHIES 2 and 3. © Ps 


NOTE - 
The iSBX board, when installed onto a host ~ 
_ board, occupies an additional card slot adjacent to - 
the base board in an:iSBC 604/614 Cardcage. . 
‘However, the base board may. be inserted in the 
, top card slot of the cardcage.. If this is, done, no 
additional slots are required. BO 
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INTEL iSBX™ 
MULTIMODULE™ BOARD 


HOST BOARD 
INTEL SUPPLIED 
CONNECTOR 


e INTEL iSBX™ 
oh MULTIMODULE™ 
CONNECTOR 


A 


SOCKET 


0.40 (max.) 


0.80 (max.) 


1.13 (max.) CONNECTOR 


(MALE) 


; CONNECTOR 
. (FEMALE) 


0.50 (min.) 


| Figure 3. iSBX™/iSBC™ Mounting Clearance (inches) 
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iSBX™ Connector _ 
The iSBX interface connector is a 36-pin custom made 
connector that was designed by Intel especially for this 


interface. The connector is plastic with gold plated con- . | 


tact pins for maximum reliability. The connector for the 


iSBX interface was designed for high reliability and dur- . 


ability. The connection between the host board and the 
iSBX MULTIMODULE board was extensively tested 
for vibration, shock, humidity, and temperature to in- 


sure that the connection is rugged enough to be used in. 


severe environments. This connection was tested for the 
following environment: 


Vibration: Sweeping from 10 Hz to 55 Hz and back 
to 10 Hz at a distance of 0.010 inches 
peak-to-peak, lasting 15 minutes in each 


of the three planes. 


Shock: 30g’s of force for an 11-msec duration, 
three times in three planes, both sides 


(total of 18 drops). 


90% maximum relative (no condensa- 
tion). 


Humidity: 


Temperature: 0 to 55°C (32-131°F) free moving air 
across the base board and the iSBX 
MULTIMODULE board. 


Further information on the reliability testing that was 
done on this inter-connection, or reliability information 


on the iSBX MULTIMODULE boards in general, is 
contained in the Reliability Report, RR-29, ‘‘Intel iSBX” 


MULTIMODULE Boards and iSBC 80/10B Single 
Board Computer,”’ listed in the overleaf of this note. 


The male half of this connector is available from Intel in 
the form of the iSBX 960-5 package which contains five 
of the connectors. 


iSBX™ Bus Interface Signals. 


The iSBX bus interface signals are grouped into six 


basic groups, or classes, according to the functions per- = 


formed relative to the interface: . 


These signals are: 


~ CONTROL LINES 
ADDRESS LINES 
DATA LINES 
INTERRUPT LINES 

- OPTIONAL LINES © 
POWER LINES 


Many of the signals on the iSBX bus are active-low, 
meaning a low level on a control signal of the bus indi- 
cates a logic ‘‘1”’ 


value, while a low level on an address ... 
or data signal of the bus represents a logic ‘‘O’’ value... 


NOTE 
— In this application note, an active-low signal will 
_ be designated by placing a slash (/) after the 
' minemonic for the signal. 


Appendix A contains a pin assignment list of the follow- 
ing signals: 


CONTROL LINES 

The following signals are classified as control lines: 
1) COMMANDS — IORD/, IOWRT/ 

2) DMA — DMRQT, MDACK/, TDMA 


3) INITIALIZE — RESET 
4) CLOCK — MCLK 


~ 5) SYSTEM CONTROL — MWAIT/, MPST/ 


Command Lines (/O READ, I/O WRITE) 


The command lines are active-low signals which control ° 
the communication link between the host board and the 

iSBX board. An active command line conditioned by . 
chip select indicates to the iSBX board that the address - 
lines are valid and the iSBX board should perform the. 
specified operation. | 


DMA Lines (MDRQT, MDACK/, TDMA) 
The DMA lines control the communication link between 


the DMA device on the host board and the iSBX mod- 
~ ule. DMRQT is an-active-high output signal from the 


iSBX board to the host board’s DMA device requesting 

a DMA cycle. MDACK/ is an active-low input signal to 

the iSBX board from the host board DMA device ac- 

knowledging that the requested DMA cycle has been. 
granted. TDMA is used by the iSBC board to terminate 

DMA activity. The use of the DMA lines is optional as . 
not all host boards will provide DMA channels nor will 

all iSBX boards be capable of supporting them. 


Initialize. Line (RESET) 


_ This active-high input line to the iSBX board is gener- 


ated by the host board to put the iSBX board into a 


oe as known internal state. 


Clock Line (MCLK) 


This input line to the iSBX board is a timing signal. The 

‘clock frequency is 10 MHz (+0%, —10%), and the’ 

clock is asynchronous with respect to all other iSBX bus’ 
signals. 


System Control Lines (MWAIT/, MPST) 


These output signals from the iSBX board control the 
-. state of the system. Activé MWAIT/ (active-low) will 
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-put the CPU on the host board into a wait state, provid- 
ing additional time for the iSBX board to perform the 
requested operation. MPST/ is an. active-low signal 
(usually tied to signal ground) that informs the host 
board I/O decode logic that an iSBX module has been 
installed. a 


ADDRESS AND CHIP SELECT LINES 


The address and chip select lines are made up of the 
following signals: 


1) ADDRESS LINES — MAO, MAI, MA2 
2) CHIP SELECT LINES — MCS0/, MCS1/ 


Address Lines (MAO, MA1, MA2) 


-’ These active-high input lines to the iSBX boards are 
generally the least three significant bits of the I/O ad- 
dresses. In conjunction with the command and chip 
select lines, they establish the I/O port address being ac- 
cessed. : oo | 


- Chip Select Lines (MCSO/, MCS1/) 


These active-low input lines to the iSBX board are the 
result of the host board I/O decode logic. When active, 
the MCS/ lines condition the I/O command signals and 
thus enable communication between the iSBX board 
and the host board. 


DATA LINES (MDO-MD7) | 


There are eight bidirectional data lines: These active- 
high lines are used to transmit or receive information to 
or from the iSBX ports. MD0 is the least significant bit. 


INTERRUPT LINES (MINTRO, MINTR1) 


These active-high output lines from the iSBX board are 
used to make interrupt requests to the host board. These 


lines are jumper enabled and disabled on the host board 


via wire wrap posts. 


OPTION LINES (OPTO, OPT1) 


These two signals are reserved lines that are connected 
to wire wrap posts on both the host board and the iSBX 
MULTIMODULE board. They are for unique require- 
ments where a user needs a host board or MULTIBUS 
bus signal on the iSBX module. _ 


POWER LINES 


All host boards provide 4+ 5 volts as well as 4 12 volts to. 
the iSBX MULTIMODULE board along with signal 


ground. All power supply voltages are +5%. Table 1 
‘gives the power supply specifications for the iSBX inter- 
face. ee. BS 
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Table 1. Power Supply Specifications 


Minimum | Nominal Maximum 
(volts) | (volts) (current)* 


ee ee 


*Per iSBX MULTIMODULE board mounted on base board. 


iSBX™ BUS INTERFACING 


This.section of the application note focuses on the iSBX 


interface and design considerations related to interfac- 


ing with the iSBX bus. It discusses the way the major 
operations like READ, WRITE, and DMA work, and 
the timing diagrams associated with each. There is also a 
discussion on other considerations for designing with 
the iSBX bus. 


Bus Timing 


The AC timing specifications for the iSBX bus interface 
can be found in Appendix B of this application note. It 
should be emphasized that the interface timing between 
the host board and the iSBX MULTIMODULE board is 
very critical. This is largely due to the fact that the iSBX 
board is attached directly to the microprocessor bus. If 
the timing specifications are not met, unpredictable and 
possibly intermittent operation of the host board may 
result. 


Command Operations 


The command lines (IORD/, IOWRT) are driven from 
the hest board by three-state drivers with pull-up resis- 
tors or standard TTL totem-pole drivers. These lines in- 
dicate to the iSBX board that action is being requested. 
There are two types of operations for each command 
line and it is the iSBX board that determines which 


operation is.to be performed. . | 


READ OPERATIONS (IORD/) 

Two different types of read operations are possible. The 
first type of read is called a full speed I/O READ. The 
host board generates a valid I/O address (MA0O-MA2) 
and a valid chip select signal (MCS1/) which is then sent 
to the iSBX board; after the set-up times are met, the 
host board activates the IORD/ line. At this time, the 
iSBX board must generate valid data from the ad- 
dressed I/O port in less than 250 ns. The host board 
then reads the data and removes the READ command, 
address and chip selects. These are shown in the timing 
diagram for this operation (Figure 4). The second type 


of read operation is called an I/O READ with Wait. 


This READ is used by iSBX boards that cannot perform 
a full speed read operation. Under this operation the 
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host board generates the valid address and chip select 
signals, as in the full speed read. But this time the iSBX 
- board will activate the MWAIT/ signal, which in turn 
removes the READY input to the CPU, putting it into a 
Wait state. The CPU, however, first activates the 
IORD/ signal before going into the Wait state. After 
valid data is placed on the iSBX data bus by the iSBX 
board, the iSBX board will remove the MWAIT/ signal. 
The host board will then read the data and remove the 
command, address, and chip select lines. This. I/O 
READ with Wait operation is shown in nee 5. 


WRITE OPERATIONS (IOWRT/) 


There are also two types of write operations possible: 
the type performed is again determined by the iSBX 
board. In the full speed I/O WRITE operation, the host 
board generates a valid I/O address and chip select and 
then activates the IOWRT/ line after the necessary set- 
up times are met. The IOWRT/ line, after being acti- 
vated, will remain active for 300 ns and the data will be 
valid for 250 ns before the IOWRT/ command is re- 


MA0-MA2 


MDO-MD7 - 


moved. The host board will then remove the data, ad- 
dress, and chip select lines. after the hold times are met, 


-as shown in the nine Staten of this operon pute 


6). 


This eas write operation i is ‘the 1/0 WRITE with 


Wait operation. This WRITE is used by the iSBX 
boards that cannot write into an I/O port withthe full 
speed write specifications. The host board again 
generates valid address and chip select signals as in the 
full speed write operation. However, this time the iSBX 
board generates the MWAIT/ signal based on address 
information (chip select and MAO-MAI). The activa- 
tion of MWAIT/ causes the removal of READY to the 
CPU, thus causing the CPU to go into a Wait state. The 
iSBX board removes the MWAIT/ signal (allowing the 
CPU to leave its Wait state) when it has satisfied the 
WRITE pulse width requirements.. At this time the 
board removes the WRITE command, followed by the 


data, address, and chip select lines. This I/O WRITE 


with Wait operation can be seen in Figure 7. . 


VALID ADDRESS 


Figure 4. Full Speed I/O Read Operation 


MA0-MA2 


MWAIT! 


MDO-MD7 


VALID ADDRESS 


anita ce sae wont 


Figure 5. I/O Read with Wait Operation 


Pe 
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MA0-MA2 


IOWRT/ 


MDO-MD7 


VALID ADDRESS 


| VALID DATA 


Figure 6. Full Speed VO Write Operation 


MAO-MA2 


MWAIT/ 


1OWRTI 


MDO-MD7 


: VALID ADDRESS 


— 7 
Me gee 


VALID DATA 


Figure 7. I/O Write with Wait Operation 


iSBX™ Addressing 
The iSBX boards are addressed by the host board 


through the use of the address lines MAO, MAI and 
MA2, and the chip select lines MCSO/ and MCSI/. The . 


host board decodes the I/O addresses and in turn gener- 


ates the chip selects for the iSBX boards. In an 8-bit sys-. | 


tem the host board decodes the high order 13 address 


bits and generates the appropriate chip select corre-. 
sponding to those address bits. The low order three ad-.. 
dress bits are passed to the iSBX board via MAO-MA2. 


Thus, a host board reserves two blocks of eight I/O 
ports for each iSBX connector. There can be as many as 
three iSBX connectors per host board, therefore a total 
of 48 addresses or six blocks of eight I/O ports that can 
be reserved for the iSBX boards. Table 2 contains a list 
of the I/O addresses and their corresponding host board 
iSBX port assignments of the iSBC 80/10B and iSBC 
80/24 host boards. 
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Table 2. iSBX™ Host Board Port Assignment 

iSBX™ Connector | ... iSBX™ Port 
Number Chip Select Addresses 
MCS0/ FO-F7 
MCSI/ F8-FF 


iSBC 80/10B 
Connector 

iSBC 80/24 First 
Connector 


iSBC 80/24 Second 
Connector 


Considerations for iSBX™ Bus Interfacing 


When designing with the iSBX interface it is important 
to note that the iSBX bus is not buffered on the host 
board. Since there is no isolation between the iSBX 
board and the host board CPU bus, a short between sig- 
nal lines and power or ground could have a direct effect 
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on the CPU or the drivers and receivers associated with | 


the CPU on the host board. This must be taken into 


consideration, especially when designing and debugging ~ 


any custom designed iSBX MULTIMODULE board. It 
is usually during the development states of a product 
that these types of problems occur. One advantage to 


not buffering the iSBX bus is increased speed of data 


and command transfers. Applications requiring buffer- 
ing may add the buffers on the iSBX board. A second 
advantage to not buffering is the saving of parts costs, 
‘board real estate and development time for the host 
board. Another consideration when designing with the 


iSBX interface is, if the application to be designed re-— 
quires high throughput, like a floppy disk controller or 


a CRT controller, the designer may consider putting 
some type intelligent control of buffer RAM onto the 
iSBX board. By doing this, the transfer information can 
be stored in this buffer and the throughput of the system 
increased. 


iSBX™ BUS LOADING REQUIREMENTS — 
Loading requirements for the iSBX bus have been 


broken up into two basic categories, output specifica- 
tions and input specifications, which can be viewed in 


MDO-MD7. 
MINTRO-1 
MDRQT 


~ Tables 3 and 4. The output specifications are the re- 


quirements on the output drivers of the iSBX board and 
are the minimum drive requirements necessary: A good 
example of this would be that the data bus output 
drivers must be able to sink a minimum of 1.6 mA and 


maintain Voy at a maximum of 0.5 volts and a mini- 


mum source of 200 1A, while providing a minimum out- 
put of 2.4 volts. The input specifications are the re- 
quirements on the receivers of the iSBX board. An ex- 
ample of this would be that the loading of the address 
lines (MAO- MA2) can be no greater than 0.5 mA witha 


minimum low threshold of 0.8 volts. 


| Optional Interface Lines 


The iSBX interface has two optional lines which were 


included for the user to configure the iSBX board for 
special application needs. These two lines can be used in 
a number of ways helpful in unique situations. For ex- 
ample, they could be used as a way to get two extra in- 


~ terrupt lines down to the host board, thus yielding a 


total of four interrupt lines running between the iSBX 
MULTIMODULE board and the host board. They 
could also be used to get extra address lines, or even 


another clock signal to the iSBX board. They could also 


Table 3. Output Specifications 


(Vo. Max) | —Min(@A) | (Von Min) (PF) | 
2.4. 130 


| os | 20 || 


mwarty | mm as «| sd 0 


| | TTL 
“| OPT1-2 TTL 
MPST/ TTL 


Type? 
Receiver 


‘| MCLK ae 
OPT1-OPT2 


NOTES: 
1.: Per iSBX MULTIMODULE board. 
2. TTL=standard totem-pole output. TRI = three-state. 


3. iSBX MULTIMODULE board must connect this signal to ground. 
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be used to send a special status line to or from the iSBX 
' MULTIMODULE board. 


iSBX™ MULTIMODULE™ DESIGN 
EXAMPLE : 


This section covers the description of a custom iSBX 
MULTIMODULE board which uses the Intel 8279 Pro- 
grammable Keyboard/Display Controller. This iSBX 
board, when added to an iSBC host board, provides an 
interface to a keyboard and display. A description of 
the hardware design considerations for breadboarding 
_ the hardware is presented. Following this, a software ex- 
erciser, useful for debugging the board, is described. A 
listing for the exerciser is contained in Appendix C. 


Since the iSBX MULTIMODULE board was designed 
using the Intel 8279 Programmable Keyboard/Display 
Controller, a brief description of the 8279 is presented. 
The 8279 is a general purpose programmable keyboard 
and display I/O controller which was designed for use 
with the Intel microprocessors. The keyboard portion of 
this device is capable of providing a scanned interface to 
a 64-contact key matrix. It is also possible to interface to 
an array of sensors or a strobed keyboard, such as those 
of the Hall Effect or the ferrite variety. The 8279 pro- 
vides a variety of keyboard inputs (i.e., 2-key lockout 
and N-key rollover), and all key entries are debounced 


iSBX™ BUS CUSTOM iSBX™ BOARD 


SHIFT 


_ cee: 2 


: SLO-SL3 DECODER 
| | 
MCSO/ wie: 


iSBX™ BUS 


IORD/ 


and strobed into an 8-character FIFO. The display por- 
tion provides the user with .a scanned display interface 
for LED, incandescent, and other popular display tech- 
nologies. Both numeric and alphanumeric segment dis- 
plays may be used, as well as simple indicators. The 


8279 is used in this iSBX design example to provide an 


interface of 2-key lockout with key debounce to a 
64-character keyboard, and an interface for a 16-char- 
acter, 18-segment alphanumeric display. 


iSBX™ MULTIMODULE™ Board Design 


The iSBX board that was designed for this application 
note contains a total of three IC’s, the keyboard/display 
controller, a flip-flop, and a 3-to-8-line decoder. Figure 
8 contains a block diagram of the hardware used in this 
design example. Figure 9 contains a schematic for the 
portion of the design example resident on the custom 
iSBX board. 


The design offers the user some flexibility as to the type 
of display or keyboard to be attached. For example, if 
the application design was defined to be for a 7-seg- 
ment, 16-character display (as the 8279 is designed to 
drive), a 4-to-16-line decoder along with the display 
drivers could be added to the iSBX board. Another idea 
would be to include everything except the display drivers 
and the display on the iSBX board, and to put the dis- 


DISPLAY ELECTRONICS 


KEYBOARD 


DISPLAY 


Figure 8. ‘Block Diagram of the iSBX™ Design Example 


1-185 AFN-01931A 


—AP-96 


play and drivers’in with the keyboard. It is possible, and 

_ ‘probably desirable in some applications, to incorporate 
. some of-the display. electronics onto the iSBX MULTI- 
-- MODULE board. Some ofthe IC’s found‘in the'display 


portion of this design could also have been placed on-the 


iSBX board, as there is enough r room on the finished 
product for doing so. : Be, PI, 


The design was very easy to implement because, with the 
exception of one signal, all of the iSBX bus signals nec- 
-essary to drive the 8279 are connected directly without 
any extra logic needed. The one’signal that would not 
connect directly to:the interface is the clock signal 


~ MCLK from the bus to CLK on‘'the controller. It is not. 


possible to connect these two together as MCLK is a 10 
*- MHz signal and the 8279 requires a maximum clock sig- 
nal of 3.1 MHz to generate its internal timings. It is nec- 
essary to add a 74LS74 dual D-type flip-flop to divide 
the MCLK signal by 4 for the controller. With this: ex- 
ception, all other signals, DBO-DB7 to MDO-MD7, Ao 
to MAO, CS/ to MCS0/, ete. ‘ are connected directly 


iSBX™'CONNECTOR 
J4 P4 


RESET =~ § 
1OoW! 13 
1OR/ 15 


Moo 33 
MD1 31 
MD2 29 
MD3 27 
MOS 25 
MD5 23 
MD6 21 
Mp7 19 
MAO 
MAt 

MA2 


MCLK 
MPST/ 
MWAIT 


MCSO/ 
MCS1/ 
OPT1 
OPT2 


MINTRO 
MINTR1 


+12V 
-12V °° 2- 


GND 
GND 
GND 


pes Figure.9:° Schematic of the custom iSBX™ Board 


to the iSBX interface..To meet the timing requirements 


of the iSBX bus, a high speed version of the 8279, the 
8279-5, is used. 


The keyboard interface side ‘of the iSBX board consists 
of a 3-to-8-line decoder, which is used for scanning the 
~ keyboard ‘matrix: The 8279 scan lines SLO-SL2 are de- 
coded by a'74LS156 open-collector output: cecoder and 
“sent to the keyboard via a connector. 


: The display interface of the iSBX board consists of 


sending the scan lines and the display outputs to the dis- 
play module via a connector. The scan lines SLO-SL3 


"are sent to the display drivers, and the’ display outputs 


A0-A3 and BO- B3 are sent to an ASCII to 18- -segment 
decoder driver. The display is discussed in further detail 


- in the next section of this. appuceHon note. 


Display Module Design. | 
The display module design’ (Figure 10) consists of two 


-8-digit HDSP 6805 Alphanumeric Displays by Hewlett — 


RETURN LINES 


“282 Onane 
SCAN LINES 
TO KEYBOARD 


N Oo 2 OD uw O 
-~ @& 


TO DISPLAY 


oon DW bw 


) 
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Packard, the AC5947 ASCII to 18-segment decoder 
driver by Texas Instruments, two Signetics NE590 
Peripheral Drivers, and a 74LS122 monostable multi- 
vibrator. The display is scanned by the outputs AO-A1 
and BO-B3, which are connected to the inputs of the 
AC5947, and the SLO-SL3 outputs which are connected 


to the NES90 digit scanning circuitry. The interdigit — 


blanking is provided by the 74LS122, which prevents a 
display ghosting type effect. With the 8279 display con- 
troller it is possible for the display to have either left 
entry, where the data enters from left to right across the 
display, overflowing in the left most display position, or 
right entry, where the data enters from the right side of 
the display and all previous data shifts left. Left entry 


was chosen for this example. The controller also pro- | 


vides commands for blanking or clearing the display. 


3.9K +5V 
(TYP) 


DISPLAY CONNECTOR 
(FROM iSBX™ BOARD) 
oat 17 


: i i ET 
B3 - yi tt | 14! 
a rr as) 
B1 
BO 


AC 5947 


SEGMENT 
DECODER 


Keyboard Interface Design 


The eight output lines from the decoder on the iSBX 

board select 1-of-8 keyboard matrix rows for testing by 
the controller to see if a key depression has been made in 
the selected row. The keyboard matrix column output 
lines are connected directly to the return lines of the 
8279, RLO-RL7. Open-collector outputs presented by 
individual keys within the matrix eliminate the need for 
isolation diodes when two keys in a given column are 
depressed. The keyboard/display controller has the op- 
tion of using either scan keyboard, scan sensor matrix, 
or strobed input as modes of operation. With the scan 
keyboard mode there is a choice of using either 2-key 
lockout or N-key rollover for keyboard entry. The scan 
keyboard with 2-key lockout mode is used for this ex- 


> > 
nO oo 


HDSP _HDSP 


Qonrmoond na 
R = 


we = 


6508 6508 
DISPLAY DISPLAY 


2zrxzenr-rz 


Qo 


2.3 4 5 6 7 8 
7 4 


O00 01 O02 03 04 O5 06 07 


DIGIT 


DRIVERS NeSRY 


7 


Figure 10. Display Module Schematic 
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ample. A diagram of thé: keyboard interfaces and: matrix. - 


can be seen in ee 11. 


RETURN. LINES aA - a. | 


os re 
1 
| 
tt 
ae | 
in 
., 
1. 
. c 
| 
1 
| 
| 


TO iSBX™ BOARD | 


SCAN LINES 


Figure 11. Keyboard Matrix Schematic 


MWAIT/ 


MINIMUM SETUP TIME FOR 8279-5 “ 


MWAIT! 


{OWRT/! 


Opéiation with the iSBC 80/10B™ ees, 
Board Computer ee 


The 8279. on the iSBX eeancion | board i iS. Sanitialized: to : ; 


its mode of operation following. a system. reset. The key- . | 


board mode. of, operation is to scan the keyboard with . : 
2- key lockout,.. and. the display. mode is set for the 


16-character. left entry mode of operation. Upon receiv-., 


ing. a character from the, keyboard, the 8279 generates. _ 
an interrupt along the MINTRO line of the iSBX bus to. . 
the CPU...At this time. the. ISBC 80/. 10B° board. com... 
mences I/O read operations to the. iSBX board by. gener- ee 


ating valid. 1/O address and chip. select commands, on... 
the MAO and MCS0/ signal lines.. After the setup times .. 


are met, the 80/ 10B issues an 1/O read command. by | 


asserting the IORD/ line on the bus, and the base board ed 


reads the data from the iSBX board and removes the 
IORD/, MAO, and MCS0/ signals from the bus. After 
the data has been read in from the keyboard, it must be 
output to the display. The iSBC 80/10B board starts an 
I/O write operation by generating a valid 1/O address 
and the chip select signal with the MAO and MCSO/ 
lines. After the valid setup times are met, the LOWRT/ 


: line is activated by the base board. When, the data. has 
. been valid for ’a minimum of 250 ns, the host board 
‘removes the IOWRT/ line. When the hold times have 

-- been met, the data, address and chip select lines are.also : 
removed. Figure 12. ‘shows the timing diagrams just 
| micusee | 


Figure 12. System Timing Diagrams » 
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Breadboarding the Design 


When doing the layout of the breadboard, it is also nec- 
essary to take into consideration the space required by 
the mounting holes and to plan the positioning of the 
components accordingly. (This information is available 
in the iSBX Bus Specification Manual.) 


When attaching the breadboarded design, which typi- 
cally contains raised wirewrap posts, it is necessary to 
raise the breadboard well above the host board. This 
can be accomplished by building a small cable and put- 
ting the breadboard on longer nylon standoffs. It is not 
recommended that the cable be longer. than 15 cm (6 
in.), otherwise bus timing problems could result. 


With the breadboarding finished it is a good idea to re- 
check all wiring connections for possible errors. Also 
check all signal lines with an ohmmeter between power, 
and then ground, for potential shorts. An error at: this 
point can cause serious damage to the host board! 


Software Considerations 


The software written for this application is an exerciser 
that is used for hardware checkout. It is a small pro- 
gram designed to echo characters from the keyboard to 
the display. The software was edited, assembled, linked 
and located with an Intel development system; it was 
then debugged with an in-circuit emulator. Both the 
software and the hardware debug is covered in the next 
section of this application note. 4 


To facilitate this discussion the software exerciser is 
divided into three sections based upon the functions per- 
formed. The three functions are: | 


1) Keyboard interrupt routine 
2) Initialization and flag checking routine 
3) Character output routine 


A complete listing of the software exerciser can be 
found in Appendix C. 


KEYBOARD INTERRUPT ROUTINE 


The 8279 generates an interrupt to the CPU whenever 
data is introduced into its FIFO/Sensor RAM. The in- 
terrupt is cleared by doing a data read. Whenever a key 
on the keyboard is depressed an interrupt is generated. 
Two things are required when an interrupt occurs. First, 
the keyboard input data must be retrieved and stored. 
Second, the interrupt routine must indicate that there is 
some data ready to be output to the display. Therefore, 
a buffer is created in memory (called ‘‘BUFF’’) at loca- 
tion 3COOH to store the keyboard data. A data present 
flag is set in a register (REG. C) to indicate that data is 
ready to be output and can be found in the buffer. In 
this way the interrupt routine is used to input characters 
from the keyboard to the input buffer. The buffer is 
then read by the output routine, which sends the charac- 
ters to the display. _ 


INITIALIZATION AND FLAG CHECKING : 
ROUTINE | 


The initialization and flag checking routine first sets the 
stack pointer to the top of memory. After this the pro- 
gram proceeds to initialize the 8279 Keyboard/Display 
Controller to its proper mode of operation. The modes 
of operation used for this application note is scanned. 
keyboard with 2-key lockout for the keyboard, and 16 
characters with left entry for the display. As the 8279 
has a desired internal operating frequency of 100 kHz, 
the frequency divider chain is programmed to divide by 
19 hex, or 25 decimal. After the 8279 has been initial- 
ized, the program begins its next procedure of clearing 
the buffers. The keyboard input buffer, ‘‘BUFF’’, as 
well as the display buffer, ‘‘DBUFF’’, are both cleared 
to a blank display. This is done so that at the time of 
power up, the display will come up blank. With the 
initialization now complete, the program disables the in- 
terrupts and checks the data present flag for an indica- 
tion that data might be present for output. If the data 
present flag is set, the output character routine is called; 
if it is not set, the interrupts are enabled and the pro- 
gram loops back around to check again. In summary, 
this routine initializes the 8279 and clears the buffers, 
and then loops on the data present flag looking for an. 
indication that data is present in the input buffer. The 
input buffer is a one-byte wide buffer named ‘‘BUFF.”’ 


CHARACTER OUTPUT ROUTINE 


The character output routine brings the character in 
from ‘‘BUFF”’’ (the keyboard input buffer) and com- 
pares it to the characters located in a table. If the char- 
acter can be matched to a character in the table it is 
replaced in ‘‘BUFF’’ with the corresponding character 
located in the same position of a second table. If there is 
no match, it is compared to the code for a control char- 
acter. If there is no match with a control character, a 
compare is made to see if the character is a delete char- 
ater. When a match is found and the acceptable charac- 
ter is placed in ‘‘BUFF’’, the output routine shifts the 
data in the display buffer (Figure 13) one position to the 
left and places the character from the input buffer into 
the display buffer at position ‘‘DBUFF’’ + 15. Now that 


BASE BASE 
ADDRESS 


DBUFF +15 


ADDRESS 


NEW 
DISPLAY 


JETT TT TT yifsfepx}” 


Figure 13. Display Buffer 
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the new information is in the display, the routine copies 


the complete contents of the display buffer, ‘‘DBUFF’’, 


to ‘‘DBUFF’’ + 15 to the display. In the case of the in- 
put character being matched up with a delete character, 
all information in the display buffer is shifted to the 

right one position and the ASCII code for a blank char- 
acter is placed into the left-most position or the base ad- 
dress of ‘“‘DBUFF’’, thus making the next character sent 
to the display a blank character. In the case of a control 
character, nothing is done and the program returns to 
the flag checking routine. 


Debug Considerations 


Hardware and software debug was acconiplished using 
an iSBC 80/10B Single Board Computer, an iSBC 655 
Chassis, an Intellec® Series II Model 230 Microcom- 
puter Development System, and an ICE-80™ In-Circuit 
Emulator. 


The software was down-loaded from the disk to the 
iSBC 80/10B board using the in-circuit emulator. The 
ICE™ module ‘gives the engineer the capability of 


interrogating the iSBC system by allowing the user to 


access and display the CPU register contents, status, 
system memory contents, and all I/O devices and their 
data. 


The iSBC 80/10B board was configured to enable inter- 
rupts from the iSBX board via the interrupt 0 line 
(MINTRO), which is connected to the interrupt pin of 
the 8080 CPU. The iSBX board was attached to the 
iSBC 80/10B board via the iSBX connector. The iSBC 
80/10B board was powered-up and the iSBX board was 


checked for proper power and ground connections. The 
ICE-80 emulator was connected to the iSBC 80/10B 
board. Using the interrogation mode of the emulator, it 
is possible to check proper functioning of the iSBX 


board by sending and receiving data to/from the 8279. 


The keyboard can be tested by depressing a key on the 
keyboard and then examining the FIFO/Sensor RAM to 
see if the data was entered. The display RAM can alsc 
be read and written to for testing the interface to the 
display. 7 


After this initial checking of the iSBX board, the soft- 
ware exerciser can then be down-loaded with the ICE 
module to further check the board. 


SUMMARY 

The objective of this application note is to introduce the 
reader to the iSBX MULTIMODULE concept for ex- 
panding a single board computer’s functionality, and to 
illustrate how. a designer can use this concept with either 
standard or custom iSBX boards. In contrast to system 
expansion using MULTIBUS-compatible boards, iSBX 
MULTIMODULE boards provide smaller, lower cost, 
incremental expansion. This application note explains 
how a custom iSBX board can be designed and de- 
bugged. Using this capability, it is now possible to more 
quickly add new VLSI technology to systems as the 
technology becomes available. Intel will continue to 
provide new iSBX MULTIMODULE boards and, be- 
cause of the the publication of the iSBX Bus Specifica- 
tion and this application note, it will be easier for Intel’s 
customers to also design and build their own custom 
ISBX boards. 
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APPENDIX A 
iSBX™ SIGNAL PIN ASSIGNMENTS 


po mpaTa Bio 
DI 32 | MDAcK 
MD2 MDATA Bit 2 30 Option 0 
OPT1 Option 1 
TDMA 
CSO 
CSI 


+5V +5 Volts 


D 
D 


MINTRO- M Interrupt 0 
i Reserved 


MCLK M Clock | 


—12 Volts 


5 
fe) 
= 
v2) 
ws 
a 
2) 
= 
o 
O 
fe} 
= 
=| 
pe) 
5 
a. 


4 


< <= 
>| > | > 
< = 
>| >| > 
OQ. on 
on oO. 
Sigigs 
rile 


2 

2 

2 

2 

2 

1 

1 

1 

12 

10 
4 


All undefined pins are reserved for future use. 


8 
6 
4 
2 
0 
8 
6 
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APPENDIX B 
iSBX™ MULTIMODULE™ BOARD I/O AC SPECIFICATIONS 


Address stable after read 
Read pulse width 
Data valid from read 


Data float after read 


[ Dack setup to VOM 


MWAIT/ to valid read data lc eee el 


MWAIT/ to WRT CMD 


. Required only if WAIT is activated. 
. If MWAIT/ not activated. 
. To be specified by each iSBX MULTIMODULE board. 


For a more complete definition of symbols refer to iSBX Bus Specification, 142686-001. 
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APPENDIX C 


LISTING FOR THE iSBX™ DESIGN EXAMPLE SOFTWARE EXERCISER 


OBU 


0039 


0040 
0060 
0070 


0080 
0090 


00D8 


3C00 
3D00 


0000 
0001 


0038 
0038 


003B 
OO3E 
0040 
0042 
0044 
0046 
0048 
004A 
004C 
004F 
0050 
0052 
0055 
0056 
0057 
0058 


005B 
005C 
005D 
OOSE 
0061 
0064 
0065 


F3 
C33B00 


C3D100 


31FF3F_ 


3E08 
D3F1 
3E39 
D3F1i 
3E08 
D3F4 
OEEO 
21003C 
71 
O60F 


210F3D 


71 
2B 
05 
C25500 


F3 
AF 
B9 
CA6400 
CD6800 
FB 
C35B00 


Cc 
4: , 
za eg 
7 


> pa ’ 
Cia eS 


OU Mas OU a® wD 


WWD OND AY | 
KB OWUOMWHHRA UP WN 


WwW 
Ww 


Www ww Ww 
aww nU & 


39 


SOURCE STATEMENT 

PASSES EERE ODE ODE EOI O HOBIE ODED E ONO IOE IO CEI O HOE AO OO 
* * 
7% THIS PROGRAM WAS USED AS AN EXAMPLE FOR EXERCISING THE * 
3* 6279 188X MULTIMODULE BUILT FOR THIS APPLICATION NOTE. * 
Ae ; : Lhe 7 beer Me 
TSTORRGOSD EST ERSEEL SERS UTELS ESTP ES SO ECE L OUEST CESEECAV ENTE ESI ELON ELAR SET ERT ES 
RerrerrrrerErEenreLieiec at eee eee 
; PROGRAM EQUATES. a 

PERE HO BOE OB OER O BIO E OE OEE OBOE OHI E ECO HCA EEO EO HIOE TOE OBE OE oO OE 
DATAAD i EQU OFOH ~° + PORT ADDRESS TO-READ OR WRITE 

; ?/DATA TO/OR FROM KEYBOARD/DISPLAY 

CMDAD © EQU OF1H ? PORT ADDRESS TO SEND COMMANDS 


7/TO KEYBOARD/DISPLAY 


MODEO | EQU 08H 3 CONTROL CHAR. TO SET 


‘?/KEYBOARD/DISPLAY MODE FOR 
¢/(2 KEY LOCKOUT,16 CHAR LEFT ENTRY 


. PROGCK EQu 39H : CONTROL CHAR. TO SET 8279 CLK 
; - g/T0-100 KHZ INTERNAL TIMING 
RDFIFO EQu 40H ¢ CONTROL CHAR. TO READ KEYBOARD 
RDRAM ; EQU 60H ? CONTROL CHAR. TO READ DISPLAY RAM 
RDRAMA : EQU 70H ¢ CONTROL: CHAR. TO READ DISPLAY RAM 
; a s/AUTO INCREMENT 
. WRRAM EQU 80H ; CONTL CHAR, TO WRITE TO DISPLAY RAM 
WRRAMA EQu 90H : CONTL CHAR. TO WRITE TO DISPLAY 
s/RAM AUTO INCREMENT 
CLR EQU . OD8H : CONTROL CHAR. TO CLEAR OR BLANK 
‘ 3 /DISPLAY ; 
BUFF EQU 3C0O0H ? ADDRESS OF KEYBOARD INPUT BUFFER 
DBUFF EQuU 3D00H * ADDRESS OF DISPLAY BUFFER 
PRE EE EERE EERE EEE ER EEE EERE EERE KEE EERE REE EEE EEK EERE ERE E EEE EE EEE EE EERE EE ES 
STARTS DI 
a JMP BEGIN 
PRRRERRROOKREREREERRERES «= RST 7 ENTRY POINT «= €¥8EERRERRERERERE EEE EERE EERE EE ES 
ORG 38H 
_JMP INT 


PACER EOE O OEIC EOE EOI OCOD EEA EO ICES EGO ISAO TEE 


; INITIALIZE PROGRAM 
? AND KEY BOARD DISPLAY CONTROLLER 
?. P : 
BEGINS LXI SP,3FFEH | ? INITIALIZE STACK PT 
MVI A, MODEO ; GET CONTROL CHAR, © 
OUT CMDAD ? SET KEYBOARD/DISPLAY MODE 
MvI A, PROGCK : GET CONTROL CHAR. 
OUT CMDAD 3 SET 8279 CLK FOR 100 KHz 
MVI A,CLR 3 GET CONTROL CHAR. 
OUT CMDAD ? CLEAR OR BLANK DISPLAY 
MVI C,0E0H | a Sf i: 
LXI H, BUFF ; SET POINTER TO INPUT BUFFER 
MOV “M,C: "3 CLEAR INPUT BUFFER. TO BLANK CODE 
MVI B,OFH ? SET COUNTER = 15 
LXI H,DBUFF+0FH + SET POINTER TO DBUFF +15 
ZDBUFF MOV M,C ; CLEAR DISPLAY BUFFER TO 
DCX H ;/DISPLAY BUFFER +15 TO CODE 
DCR B 3/FOR CLEARING OR BLANKING OUT 
JNZ ZDBUFF ?/THE DISPLAY 
SEEKER KEKE RE EEE KE ER KERKE ERK EREEE REE EERE EKRKE REE KER ERE EKER EEKEEKKKAKKERERES 
2 THIS IS THE BACKGROUND PROGRAM 
; WHICH LOOPS CHECKING FOR THE DATA PRESENT FLAG 
v 
CKFLAG: DI ; DISABLE INTERRUPTS 
XRA A ;/CLEAR A REG AND COMPARE WITH 
CMP Cc 7/C REG CHECKING FOR DATA PRESENT 
JZ LABEL :/IF PRESENT CALL OUTPT 
CALL OUTPT :/TO DISPLAY CHAR. 
LABEL: EI :/1F NO DATA PRESENT ENABLE 
JMP CKFLAG ;/INTERRUPTS AND JMP BACK 
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0068 
006B 
006D 
0070 
0073 
0074 
0077 
0078 
007B 
007C 
007D 
0080 
0081 
0082 
0085 
0086 
0088 
008B 
OO08E 
OO8F 
0090 
0091 
0092 
0093 
0094 
0095 
0098 
0098 
OO9E 
00A0 
00A3 
OOA4 
OOA6 
OO0A7 
OOA8 
OOAB 
OOAD 


OOAE 
00B0 
00B3 
00B6 
00B7 
00B8 
00B9 
OOBA 
OOBB 
OOBC 
00BD 
00Cc0 
00C1 
00C3 


00C6 
00cs8 
0OCB 
00CcD 
00D0 


00D1 
00D3 
00D5 
00D7 
OODA 
0ODB 
00DD 


3A003C 
062B 
21DE00 
110901 
BE 
CA8000 
05 
CAC600 
23 

13 
C37300 
EB 

TE 
21003C 


C28E00 
3A003C 
320F3D 
0610 
21003D 
TE 
D3FO 
23 

05 
C2A300 
0E00 
c9 


060F 
110F3D 
210E3D 
TE 


C2B600 
EB 
36E0 
C39E00 


FEFA 
CA3B00 
FEFS 
CAAEOO 
c9 
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FERRER RR EERE EERE AREA EERE EERE REE EE EERE SEER SEERA EEE REREERRESERERE EERE ERE EE ERE 


e 
a 


; 
OUTPT: 


COMPARE: 


MATCHs 


LOOP1: 


LOOPAS: 


LOOP2: 


° 
id 
e 
2 
e 
° 
e 
’ 
D 


LOOPB: 


MvI 
RET 


BUFF 

H, TABLE1 
D,TABLE2 
M 

MATCH 

B 
CONTROL 


LOOP! 
BUFF 
DBUFF+OFH 
B,10H 
H, OBUFF 
A,™ 
DATAAD 
H 

B 

LOOP2 
C,0H 


OUTPUT CHARACTER TO DISPLAY 


LOAD A WITH KEYBOARD DATA 

SET COUNTER MAX POSSIBLE CHAR. 
SET POINTER TO INPUT TABLE 
SET POINTER TO OUTPUT TABLE 
COMPARE KEYBD DATA TO INPUT 
:/TABLE IF = JMP TO MATCH 

3/ELSE DECREMENT COUNTER IF 0 
:/JMP TO CONTROL 

3/ELSE INCREMENT BOTH TABLE 
:/POINTERS AND JMP TO COMPARE 


we Ge We TO TO 


: IF MATCH CHANGE INPUT WITH 
s;/OUTPT DATA AND PLACE IN BUFF 


+ SET COUNTER = TO 15 

3 POINTER TO FIRST LOC IN DBUFF 
7 POINTER TO 2ND LOC IN DBUFF 

¢ READ HIGH POINTER FROM DBUFF 
3/UPDATE HIGH POINTER 


SHIFT DATA LEFT IN D BUFF 
UPDATE LOW POINTER 


¢ TEST IF DONE 

?/AND GO BACK IF NOT 

s/ELSE READ KEYBOARD DATA 
3/AND PLACE IT IN THE DBUFF 
3 SET COUNTER = 16 

¢ SET POINTER = DBUFF 1ST POS. 
7/READ 1 BYTE FROM DBUFF 
3/AND SENT IT TO DISPLAY 

3 UPDATE POINTER 

s/AND TEST IF DONE 

3/GO BACK IF NOT DONE 

3/ELSE CLR DATA PRESENT FLAG 
7/AND RETURN 


COREE EERE ERE E EERE EERE REE ERR EERE REE ER EA RRE ERE ERE EER EES REECE ERE REESE 
CHARACTER DOFLETE 


ELETE: 


MVI 
LXI 
LXI 
MOV 
DCX 
XCHG 
MOV 
DCX 
XCHG 
DCR 
JNZ 
XCHG 
MVI 
JMP 


OR RUB OUT 


B,OFH 


D,DBUFF+0OFH 
H,DBUFF+0EH 


A, 
H 


M,A 
H 


B 
LOOPB 


M,OEOH 
LOOPA 


¢ SET COUNTER =15 

* SET POINTER = DBUFF+15 

+ SET POINTER = DBUFF+14 

¢ READ LOW POINTER FROM DBUFF 
+/UPDATE LOW POINTER 


¢ SHIFT DATA RIGHT IN DBUFF 
s/UPDATE HIGH POINTER 


? TEST IF DONE 

7/AND GO BACK IF NOT 
#/ELSE SET DBUFF FOR 
#/CODE TO BLANK DISPLAY 
3/AND JMP TO LOOPA 


PERERA EERE RR ERE ORE EERE EERE EEE EEE EE ER EER EERE RE RES EER EERE EERE RRS ERE E EEE EERE 
CHECK IF CHARACTER IS 


3 
; 
; 
Cc 


2 
o 
e 
’ 
e 
, 
e 
, 
I 


ONTROL: 


OFAH 
BEGIN 
OF 9H 
DELETE 


A CONTROL OR DELETE CHARACTER 


3 COMPARE FOR CONTROL CHAR. 
7/IF CONTROL JMP TO BEGIN 
s/ELSE COMP, FOR DELETE CHAR. 
7/IF DELETE JMP TO DELETE 
#/ELSE RETURN 


EEE KEK EERE REE ERE EER ER EERE KERR EERE ERE RRA EE ERE ERE EREEESERERESEEES EER EERE EER ES 
KEYBOARD INPUT 
INTERRUPT ROUTINE 


NTS 


A,RDFIFO 
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GET CONTL CHAR. TO READ FIFO 
SET 8279 FOR READ MODE 

READ KEYBOARD DATA IN 

SET POINTER TO BUFF 

7/AND STORE KEYBOARD DATA 
*/THEN SET DATA PRESENT FLAG 
3/AND RETURN 


=e te Ge te 
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00DE 
OODF 
00E0 
00E1 
00E2 
00E3 
00E4 
OOES 
Q0E6 
00E7 
00E8 
00E9 
OOEA 
OOEB 
00EC 
O0ED 
O0EE 
OOEF 
00FO 
OOF4 
00F2 
00F3 
00F4 
00F5 
00F6 
00F7 
O0F8 
O0F9 
OOFA 
OOFB 
OOFC 
OOFD 
OOFE 
OOFF 
0100 
0104 


0102 


0103 
0104 
0105 
0106 
0107 
0108 


158 


159 
160 


162, 


163 


“164 


165_ 


166 - 


167 © 


; 
3 
; 
; 
T 


poet: . DB 
DB 
DB 
DB 
De 


DB 


FERREREEEE REESE ESE RE RATESHEET 
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TABLE 1 


_ ACCEPTABLE INPUT CHARACTERS FROM KEYBOARD 


ODEN, OFFH, OEFH, OFEH, DESH, OFS, OFEH, OCH 
SEHD CRED Ue OD anc h she Qerurreen roan 
OSH, OEDH, OE6H,OFSH OCI, OF 7H, ODDH, OE7H 
OFDH, ODFH, OCH, OD4H, ODCH, OF4H, OECH, OF AH 
OFCH, OCOH ,OCEH,ODOH, 098H, OR2H, OCFH, OAAK 


_OEBH, OE 3H, 0D8H 
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0109 
010A 
010B 
010C 
010D 
010E 
010F 
0110 
0111 


0112 
0113 


0114 
0115 
0116 
0117 
0118 
0119 
O11A 
011B 
011C 
011D 
O11E 
O11F 
0120 
0121 
0122 
0123 
0124 
0125 
0126 
0127 
0128 
0129 
012A 
012B 
012C 
012D 
O12E 
012F 
0130 
0131 
0132 
0133 
0000 


PUBLIC SYMBOLS 


EXTERNAL SYMBOLS 


USER SYMBOLS 
0038 BUFF 

00FO DBUFF 
OO9E LOOPB 
0060 RDRAMA 


BEGIN 
DATAAD 
LOOPA 
RDRAM 
ZOBUFF 


A 


A 
A 
A 
A 


ASSEMBLY 


0055 


COMPLETE, 


169 
170 
171 
172 
173 


174 


176 


177 


178 


179 


NO 


; 
; 
, 
3 
TABLE23 


A 3c00 
A 3D00 
A 00B6 
A 0070 


ERRORS 


DB 


0B 


OB 


DB 


DB 


DB 


END 


CKFLAG A 005B 
DELETE A OOAE 
MATCH A 0080 
START A 0000 
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TABLE 2 
ACCEPTABLE OUTPUT CHARACTERS TO DISPLAY 


O0C1H,0C2H,0C3H,0C4H,0C5H,0C6H,0C7H,0C8H 


0C9H,0CAH, OCBH,0CCH,0CDH,0CEH,0CFH,ODOH 


0D1H,0D2H,0D3H,0D4H,0D5H,0D6H,0D7H,0D8H 


0D9H,ODAH,OF1H,OF2H,0F3H, OF 4H,0F5H,0F6H 


OF7H,OF8H,0F9H, OFOH, OFDH, VEBH, OEOH, OEAH 


OEFH,OEEH, 


START 


CLR 
INT 
MODEO 
TABLE1 


02DH 


A 00D8 
A 0OD1 
A 0008 
A OODE 
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CMDAD 
LABEL 
OUTPT 
TABLE2 


> PrP > 


OOF! 
0064 
0068 
0109 


COMPAR A 


LOOP1 


A 


PROGCK A 


WRRAM 


A 


0073 
OO8E 
0039 
0080 


eee TST TESTICLES CCCCLCOSOSTOSICILLSTCCSTS STILTS CTT TTT tel Tete tet i sets r it eel i ttt 


CONTRO A 00C6 
LOOP2 A 00A3 
RDFIFO A 0040 
WRRAMA A 0090 
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REPRINT ~~ AR-48 


February 1, 1978 


Technology 


CROP ASICS: Pa r t . i 


Reduce your .C-based system cesign time 
by using single-board microcomputers. Assembled boards 
in the SBC-80 series offer stock answers to custom demands. 


System designers eager to take advantage of the 
dramatically increased capabilities of micro- 
computers have been hindered two ways: Their pro- 
duction volumes have been too low to amortize soft- 
ware and hardware development costs effectively, or 
hardware subtleties and test requirements have con- 
fined them to fully assembled and tested computer 
subsystems. But now those obstacles are overcome 
with families of fully assembled and tested micro- 
computers and system-expansion boards like the Intel 
SBC-80 series. They are ready-to-use, flexible and 
inexpensive—prices range from just $195 to $825 in 
unit quantities. 

The main members of the SBC-80 family are the 
80/04, 80/05, 80/10A, 80/20 and 80/20-4 central- 
processor boards, with either an 8080A or 8085 micro- 
processor acting as the master CPU (Table 1). Most 
of the boards measure 6.75: X 12 in. and contain the 
CPU, clock, read/write memory, control ROM, I/O 
ports, serial communications interface and bus-con- 
trol logic. 

I/O interfacing is an area where design flexibility 
is essential to meet changing requirements efficiently. 
The programmable parallel and serial I/O structures 
of the boards make them versatile enough to do just 
that. What’s more, upgrading system performance i is 
easy thanks to the SBC-80 system bus, the Multibus, 
which permits modular performance expansion. 


The Multibus provides a defined, standard interface _ 


between the SBC-80 single-board computers and ex- 
pansion boards. As many as 16 SBC-80 family boards 
can simultaneously share the bus. . 


All in the SBC-80 family 
As exemplified by the block diagram of the 


SBC-80/10A (Fig. 1), the SBC-80 microcomputer sys- 
tem has all that’s needed for many applications. The _ 
SBC-80/10A is the oldest board in the family and has | 


been widely imitated since it was one of the first 
“standardized” microcomputers commercially avail- 
able. 3 

The CPU section of the 80/10A board consists of 


George Adams, Product Line Manager, Single-Chip Micro- 
computers, Intel Corp., 3065 Bowers Ave., Santa Clara, 
CA 95051. 
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the 8080A CPU, the 8224 clock generator and the 8238 
system controller. Capable of fetching and executing 
any of the 8080A’s 78 instructions, the CPU section 
can respond to interrupt requests originating on and 
off the board. (For more about the 8080A, see “Micro- 
processor Basics, Part 2,” ED No. 10, May 10, 1976, 
p. 84). 

The system-bus interface section includes an assort- 
ment of circuits to gate the interrupt and hold re- 
quests, the ready signals, and a system-reset signal. 
Other circuits drive the various control lines. Two 
8216s help drive the bidirectional data bus, and six 
8226s drive the external system-data and address 
buses as part of the SBC-80/10A’s Multibus interface. 

The RAM section of the 80/10A consists of 1024 
bytes of static MOS memory. For program storage, 
up to 8192 bytes of ROM can be mounted on the board 
in 1024-byte increments by means of a 2708 or 8708 
EPROM, an 8308 mask-programmed ROM, or in 2048 


byte increments via the 2716 EPROM or 2316 ROM. 
A serial interface on the board uses an 8251 pro- 


grammable universal synchronous/asynchronous 
receiver/transmitter to provide a serial-data channel. 
The serial port operates at programmable rates up to 
38,400 baud (synchronously) or 19,200 baud (asynchro- 
nously) with a choice of character length, number of 
stop bits, and even, odd or no parity. On-board 
interfaces provide direct EIA RS-232 or teletypewriter 
current-loop compatibility. 

Two 8255 programmable peripheral interface 


circuits provide 48 I/O lines for transferring data to 


or from peripheral devices. Eight already-committed 


_ lines have bidirectional drivers and termination 
~ networks permanently installed, so that they can be 


inputs, outputs or bidirectional (jumper-selectable). 
The other 40 lines are uncommitted. On-board sockets 


_permit drivers and termination networks to be in- 


stalled, as needed. Since software configures the I/O 
lines, I/O can be customized for every application. 


~The 80/10A also responds to a single-level interrupt 


that can originate from one of many sources, the 
USART, programmable I/O and two user-designated 
interrupt-request lines. When an interrupt is recog- 
nized, a Restart-7 instruction is generated, and the 
processor accesses location 38,, to get Me starting 
address of the service routine. | 

System expansion and support are secible with a 
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wide variety of alternate-source CPU, memory, and 
I/O boards (Tables 2 and 3). Up to 65,536 bytes of ROM, 
PROM or RAM can be accessed by one 80/10A. 
Expandable backplanes and card cages are also avail- 
able to support multiboard systems. 


Interfacing starts with the bus 


Although the SBC-80/10A is a complete micro- 
computer system, it can be expanded readily or it can 
serve as a primary master controller for other micro- 
computer cards. The 80/10A has five edge connectors, 
three on the top of the board and two on the backplane, 
or bottom, side. Two of the “top” connectors, J; and 
Jo, serve as parallel I/O ports, while J3 is a serial I/O 


RS 232C 
COMPATIBLE 
DEVICE TTY 


SERIAL SERIAL 
DATA DATA 
INTER- INTER. 


CONTROL 
INTERFACE 


CONTROL 
INTERFACE 


port. All parallel I/O lines on the 50-contact J; and 
J2 connector areas are paired with an independent 
signal/ground pin to permit alternate signal/ground 
wiring when using flat-cable interconnects. Serial port 
J3 uses a 26-contact PC-edge connector to provide 
interfaces for both RS-232 and current-loop devices. 

To communicate with other system-compatible 
boards, the 80/10A uses the 86-pin Multibus (P;). To 
provide accessible test points, the 80/10A has a 60- 
pin edge connector (P2). The control signals on the 
Multibus provide the real power and capability in 
control applications. 

Of the 86 pins that make up the Multibus, 24 are 
assigned to power and ground, 16 to addressing, eight 
to bidirectional data, and 12 to signal and control 


USER DESIGNATED 
PERIPHERALS 


FACE FACE a ee 
1 48 PROGRAMMABLE 
INTERRUPT PARALLEL I/O LINES 
“RS 232C TTY REQUEST 
INTERFACE INTERFACE Cine 
DRIVER/TERMINATOR 
INTERFACE 
\ 7 JUMPER 2 INTERRUPT 
SELECTABLE REQUEST 
LINES 8080A 
CPU 


8K x 8 PROGRAMMABLE 
ROM/PROM COMMUNICATIONS 
MEMORY INTERFACE 


(SOCKETS) (USART) 


BUS INTERRUPT 
REQUEST LINE 


DATA BUS 


PROGRAMMABLE 
PERIPHERAL 
INTERFACE 


2 INTERRUPT SBC-80/10 
REQUEST SYSTEM 
BUS MEMORY 
i Maree SF AND 
aa eE EL V0 
EXPANSION 


Interrupts originating from the Programmable Communications Interface and Programmable Peripheral Interface are jumper selectable. 


1. Based on an 8080A uP, the 80/10A microcomputer has 
a straightforward design suitable for general-purpose 
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PROM/ROM 


computing and control. The board has 48 programmable 
I/O lines and serial interfaces. 
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1/0 DEDICATED TO 
MASTER. NO. | 


CPU MASTER: NO.| 
SBC 80/20 


COMMON sane 
SPEED MATH 
PROCESSOR. 


(SBC. 310) 


uae | 


5 1" BUS CONTROL | | 
oe 


2.- The Multibus interface for the SBC-80 CPU boards not 
only. permits. simultaneous multiprocessing, but also 
enables several processors to share the same bus and 


(these 12 are defined in Table 4). The remaining 26 
pins are unassigned at this point. Higher capability 
SBC-80 products, though, are in development. These 
boards will use many of the unassigned lines (eight 
unassigned pins are allocated for additional bidirec- 
tional data lines). The remaining lines provide multi- 
level (eight) interrupt lines, various control lines and 
a multimaster, bus-arbitration control structure (Fig. 
2). Address and data lines are three-state, and the 
interrupt and control lines are open-collector. | 
Boards using the Multibus have a master-slave 
relationship: A bus master—such as an SBC 80 CPU 
board, a DMA controller or a diskette controller—can 
control the command and address lines. Conversely, 
slave boards—such as a memory, I/O-expansion or . 
mathematics boards—cannot control the bus. 


Arbitration resolves. priority disputes 


In multimaster systems, the bus-arbitration logic 
uses the CCLK signal of the bus to provide a timing 
reference to help satisfy many simultaneous requests 
for bus control. As a result, different speed masters 


MULTI BUS 


1 DEDICATED TO 
MASTER NO.2 © 


on 
SZ 


COMMON 1/0 


|. ANO PERIPHERALS —— 
= 


peripheral devices. Arbitration logic on the CPU boards 
decides which board gets on the bus first if several units 
simultaneously access the bus. 


BUS CONTROL 


CPU MASTER NO. 2 
ze 80/05 


can share resources on one bus. Actual transfers on 
the bus proceed asynchronously with respect to the 
bus clock. Once bus access is granted, single or 
multiple read/write transfers can proceed at up to 150 
kbytes/s for CPU operations and up to 1 Mbyte/s for 
DMA operations. The bus has a bandwidth of 5 
Mbytes/s so that future performance enhancements 
may be directly supported. 

Both serial and parallel modes of bus-priority reso- 
lution are available. In the serial mode, up to three 
masters can share the system bus, with requests 
ordered on the basis of bus location. Each master on 
the bus notifies the next one down in priority when 
it needs to use the bus, and monitors the bus-request 
status of the closest higher-priority master. With an 
external priority network, up to 16 masters can share 
the bus. 

The dual-bus nature of the Multibus permits each 


- processor-based master within the system to retain 


its own local memory and I/O, which it uses for most 
operations. Such local operations occur entirely on the 
individual board and don’t require the system bus. 

In contrast to the dual bus architecture, all masters 


Table 1. Comparison of SBC-80 CPUs 


SBC 80/04 


CPU Ree os sZt 
EPROM capacity (bytes) ; 
(with 2716) i 

(with 2708) 
RAM (bytes) 
Programmable parallel 


8085 


Interrupt levels 4 
Multibus interface 


Price (unit quantity) $350 


"Notes: 'Provided by 8085 CPU SID and SOD serial 1/O lines. 2Optional SBC 530 TTY interface is available. 
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/| SBC iui 


512°. 


1/0 lines | res — 22 Bh oe. 
Serial 1/O capability —RS232C ~8=30OS{|—s RS232C. CO 
. ~SID/SOD!: 2 | = =SID/SOD!. 2 
Timers . | 4 


‘Multi-master 


“SBC. 80/10A SBC 80/20 SBC 80/20-4 


080A 8080A 8080A 


4g 


48 ae 48 
RS232C/TTY | “RS232C2 RS232C2 
USART — -| USART. USART 

0 2 2 

1 8 8 
Single-master | Multi-master Multi-master 
$495 $735 $825 
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Table 2. Additional SBC support boards in multimaster/single-bus systems use the common 


Bice bus for all instruction or data fetches or whenever 
| Function [ose | desrton | (unit data must be written to output devices or memory. 
qty) Rapidly, then, the system bus becomes the bottleneck 


cae Ser AS Eerie dean tay Pe for over-all system throughput. Masters in SBC-80 
SBC 048 48 kbyte dynamic RAM | $1860 systems only use the Multibus when data or instruc- 

See ooae eerie OMOs siete ecgas tions are resident in common, or global, memory or 

he ae 26 hour bat-| I/O. Since masters can request the Multibus simulta- 


EPROM SBC 416 16 kbytes using 27081 § 205 neously, on-board arbritration logic resolves any mul- 
type (1024 x 8) EPROM es tiple contention. 


SBC 508* 32 input tines/32 out- 
put lines, all buf- 
fered/terminated 


ae 


Digital 
1/0 


Examine board performance 


$ 400 A look at the entire family of SBC-80 micro- 

computers reveals varied levels of performance. All 

five boards are inexpensive, but the most inexpensive 

is the 80/04, which costs $99 in 100-unit quantities, 

and is intended for stand-alone applications. To get 

$ 395 the cost down, the board was designed to use the 8085 
CPU and the 8155 RAM, timer and I/O circuit. 

The 80/04 contains an 8085 CPU, 256 bytes of RAM, 

space for up to 4 kbytes of EPROM (two 2716 EPROMs, 

or two 2708 EPROMs), 22 programmable parallel I/O 

lines with sockets for buffer and termination options, 


$ 650 a 14-bit programmable timer/event counter, and pro- 
vision for an RS-232-C serial port using the 8085 
SID/SOD serial interface. The board can also house 
an on-board +5-V regulator, so an unregulated voltage 
can be connected. : 
The next step up, the 80/05, has the same architec- 
ture and connector types and pinouts as the 80/04. 
Direct software compatibility is achieved with the 
same CPU along with the same RAM, ROM, I/O, and 
$ 395 


SBC 517 48 programmable par- 
allel lines with — full 
buffering/termination 
options, full RS232C 
port, 1 ms real-time 
clock, and 8-line inter- 
rupt control 


SBC 519* 72 programmable par- 
allel lines with full 
buffering/termination 
options, real-time 
clock (interval is 
jumper selectable to 
0.5, 1, 2, or 4 ms), and 
8-level programmable 
interrupt control. 


Four programmable 
synchronous/asyn- 
chronous serial ports, 
each with: program- 
mable baud rates, pro- 
grammable data for- 
mats, programmable 
interrupt control, 16 
RS232C buffered pro- 
grammable parallel 
1/0 lines configured as 
a Bell Model 801 auto- 
matic calling unit in- 
terface. Two program- 
mable 16-bit interval 
timers (usable as real- 
time clocks), and soft- 
ware selectable loop- 
back of serial ports for 
diagnostic use. 


Communi-| SBC 534 


cations 


timer addressing. However, the 80/05 contains twice 
as much RAM as the 80/04. And since the 80/05 has 
the full Multibus multimaster interface, 80/05-based 
systems can be expanded with any of the Multibus- 
compatible boards from Intel or other suppliers. 
The SBC-80/10A comes next. It provides more on- 
board memory and I/O for systems requiring ex- 
panded on-board resources. Based on the 8080A CPU, 
the board contains 1 kbyte of RAM, up to 8 kbytes 
of EPROM/ROM, 48 programmable parallel I/O lines, 
a full USART serial port with RS-232-C and tele- 


SBC 108 
SBC 116 
SBC 310* 
Peripheral | SBC 201 

control 
SBC 202 
DMA SBC 501 

control 

"Requires +5 V only. 
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SBC 556* 


48 optically isolated 
lines; 24 input 16 out- 
put, and 8 program- 
mable (in/out), 8-level 
programmable _inter- 
rupt control, and 1 ms 
real-time clock. 
16/8 (single-ended/|$ 895 
differential) 12-bit a/d 
channels; user expan- 

dable on-board to 

32/16 channels 


Four 12-bit d/a chan- 
nels 


Analog SBC 711* 


Ae) 


Same as SBC 104, ex- 
cept has 8 kbytes of 
dynamic RAM 


Same as SBC 104, ex- 
cept has 16 kbytes of 
dynamic RAM 


High speed mathema- 
tics processor includ- 
ing floating-point ca- 
pability (32 bit). 
Dual single-density dis- 
kette controller 


SBC 724* 


SBC. 732* Combination analog} $1125 
1/0; same a/d capabili- 
ty as SBC 711 plus 2 


d/a channels 


8 kbytes capacity|$ 715 
(sockets) using 2716 
(2 k x 8) EPROM or 4 
k using 2708, 4 kbytes 
dynamic RAM, 48 pro- 
grammable parallel 
I/O lines, with full buf- 
fering/termination, as | 
options. RS-232C port, 
a 1 ms real-time clock, 
and an eight-line inter- 

rupt control 


High-speed 
math 


Combina- | SBC 104 
tion 
memory 
and 1/0 


Quad double-density 
diskette controller 
DMA controller, up to 
1 MHz transfer rates 


typewriter interfaces, and a full Multibus interface 
(but only single-master capability, the board has no 


multimaster capability), Intended for single-CPU sys- 


tems with only one other Multibus peripheral con- 
troller, the 80/10A can interface with such as the 
SBC-201 or SBC-202 single and double-density dis- 
kette controllers, or the SBC-501 DMA, controller. 
System designers requiring the same on-board I/O 
capability as. the SBC-80/10A but with more RAM, 
more efficient real-time capability, and full multi- 
master Multibus control can go further up the ladder 
to the SBC-80/20 or SBC-80/20-4. These boards differ 
only in that the 80/20 contains 2 kbytes of RAM and 
the 80/20-4 contains 4 kbytes. Both boards can hold 
up to 8192 bytes of ROM or EPROM, handle up 


SWITCHES 


CONTACTS 


BIDIRECTIONAL DRIVERS 
ANO TERMINATORS 


INTERPROCESSOR BUS 
(TO SECOND SBC 80) 


3. Programmable 1/O lines. from the SBC-80 parallel 
interfaces can be set so that they are individually program- 
mable as inputs or’ outputs (a), byte-programmable as 
inputs or outputs with handshaking (b), or bidirectional 
on a byte-programmable basis (c). 
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to eight levels of prioritized interrupt, and share the 
Multibus in the multimaster niode. Either board has 
two programmable interval timers/event counters. 
Auxiliary power buses and memory-protect control 
logic onthe board permit battery backup of the RAM. 


Take advantage of interrupts and timers 
Real-time applications frequently require that high-., 
priority programs operate on the basis of external 
events, time-of-day, or élapsed time without impact- 
ing current background processing. These multi- 
programming requirements are supported in the 
80/20 and 80/20-4 by an eight-level programmable 
interrupt controller (PIC) and two programmable: 
interval timer/event counters. The priority level of 
any event generating an interrupt request is assigned 
through jumper selection and the priority algorithm 
chosen by system software. ss | 
Any combination of interrupt levels may be masked 
by storing a single byte in the interrupt-mask register 
contained by the PIC, whose four software-selectable 
priority algorithms are described in Table 5. The PIC 
generates a unique memory address for each interrupt. 
level. These addresses are equally spaced at intervals 
of 4 or 8 bytes (software-selectable). The resulting 32 
or 64-byte block may begin at any 382 or 64-byte 
boundary in the 65,536-byte memory space. A single 
8080A jump instruction at each of these addresses 
then provides linkage to locate each interrupt service 
routine independently anywhere in memory. - 
The two programmable timers may be used to 
generate real-time clocks by requesting periodic inter- 
rupts through the PIC, so that the CPU is free to 
handle numerous other system-timing and control 
functions. The outputs and gate/trigger inputs of the 
timer/counters can be routed via jumpers to the PIC, 
the I/O driver/terminators, or the programmable 
parallel I/Q. | 
Seven software-selectable timing/counting func- 
tions are available. Either timer may be set to act as 
a rate generator (divide-by-N counter), a square-wave 
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4. By using the RMX-80 executive and the library of often- 
used subroutines, program development can be simplified 
since the subroutines. are modular and can be linked 
together, then checked out in a system prototype. _ 
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Table 3. Non-Intel SBC-compatible boards 
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ADAC Corp., 118 Cummings Park, he 
Woburn, MA 01801.(617) 935-6668 ae 4 | 
Ampex, Memory Products Div., 200 N. Nash St., i ee 
El Segundo, CA 90245.(213) 640-0150 


Analog Devices, Route 1 Industrial Park, 
- O. Box 280, Norwood, MA 02062.(617) 329-4700 


ugat Inc., 33 Perry Ave., P.O. Box 779, 
ttleboro, MA 02703. (617) 222-2202 


ae Brown, International Airport Industrial Park, 
P.O. Box 11400, Tucson, AZ 85734. (602) 294-1431 


Cybernetic. Micros neWr HE 2460 Embarcadero Way,. 
Palo Alto, CA 94303 (415) 321-0410 | 


Data Translation Inc., 23 Strathmore Road, 
Natick, MA 01760. (617) 655-5300 - 


Datacube Corp., 25 Industrial Park, 
Chelmsford, MA 01824. (617) 256-2555 


Datel Systems. |Inc., 1020 Turnpike St., euleins Si 
Canton, MA 02021. (617) 828-8000 


Digidata Corp., 8580 Dorsey Run Road, . 
Jessup, MD 0794. (301) 498-0200 — 


EDAC Corp., 1417 San Antonio Ave., 
Alameda, CA 94501.(415) 521-6600 


Electronic Engineering & Prod. Services, TE. He 
Louisville, TN 37777. (615) 984-9640 


Electronic Solutions, 7969 Engineer Rd., 
San Diego, CA 92111. ee 292-0242 
er te ale a CCE ele 


New Brunswick, NJ 08902. 1201) 545-2424 
Hal Communications Corp., Box 365B, 807 E. Green St., 
Urbana, IL 61801. ue 367-7373 
lasis, 815 W. Mau 
Sunnyvale, CA S4O86. (408) 732- 9/00 
ICOM, 6741 Variel Ave., 
Canoga Park, CA 91303. (213) 348-1391 467 
Megalogic Corp., 9650 National Road, 
Brookville, OH 45309. (513) 833- 5222 468 
Micro Memories Inc., 9438 Ironddle Ave.,. .. 
Chatsworth, CA 91311. 218) 998-0700 
Coes 
| East, Englewood, CA 80110. (303) 770-7400 | 
National Semiconductor, 2900 semiconductor Drive, 
Emeryville, CA 94608.(415) 547-5860 
Vector Electronic Products, 12460 Gladstone Ave., 
Sylmar, CA 91342.(213) 365-9661 475 


Microtec, P.O. Box 603 

Santa Clara, CA 95051. (408) 737-5000 pe ey essed lage 
Zia Tech., 10762: La Roda Drive . 

Cupertino, CA 95015: (408) 996 - 7082, 476 


Monolithic Systems Inc., 14 Inverness Drive, 
The Thomas Engineering Co., 1201 Park Ave., etn Lf ed pa 


Sunnyvale, CA 94088. 408) 733. -2919. 
North Star Computers Inc., 2465 Fourth SE, ts > 
Berkeley, CA 94710. (415) 549-0858 | ee 473 
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generator, a programmable retriggerable one-shot, or 
software or hardware-triggered strobe. One of the 
timers can be jumper-selected as an event counter, 
and either can generate an interrupt after a specified 
interval or after a specified number of events. 

The programmability of each on-board timer allows 
timing intervals from approximately 2 ys to over 60 
ms. But the two timers may be cascaded to provide 
intervals greater than 1.1 hour, in 1.86 us increments. 
In the event counter mode, external event rates up 
to 1.1 MHz may be counted. 


Flexible /O, a must for any system © 


All SBC-80 microcomputers provide 22 or 48 pro- 


grammable parallel I/O lines that, grouped as 8-bit 
ports, are fully programmable to allow enough flex- 


ibility to handle any changes in system interfacing. 
Programmability is permitted through data direction, 
control mode, interrupt handling, and 
buffer/termination. The I/O configuration for a spe- 
cific application is selected through software in- 
itialization of the parallel I/O control logic, jumper 
selection of control/interrupt line routing, and the 
particular buffer and termination devices chosen. 

- Fig. 3 illustrates the basic modes of operation that 
may be selected by software to meet application 
requirements. Mode 0 is used for slow-to-medium- 
speed interfacing where immediate handshake re- 


sponse or interrupt generation is not needed. This 


mode is extremely useful for interfacing to inputs such 
as switches or outputs such as LED indicators or 
numeric displays. 3 

Mode 1 provides handshaking lines required for 
many medium to high-speed peripherals. A typical 
output function could bea line printer; an input device 
could be an encoded keyboard or paper tape reader. 

In addition, the 80/10A and 80/20 have Mode 2, a 
bidirectional data/control structure. This interface 
may provide, for example, a communication link 
between parallel processors. 


_ The SBC-80 I/O structure also permits multiple 


options for output buffering and input termination. 
TTL drivers with 16 to 48 mA of drive can be used, 
and input lines may be terminated to minimize the 
impact of noise and cable disconnects. Any of the TTL 
drivers (four outputs) or input terminators (for inputs) 
listed in Table 6 may be inserted into sockets to provide 
proper buffering or termination. 


Like the design flexibility of the SBC-80 parallel I/O. 
structure, the serial I/O structure allows interface 


characteristics to be revised rapidly through software, 
jumper, and buffer changes. Besides the SBC-80/10A, 
the 80/20 and 80/20-4 contain the USART serial 
channel. These boards provide RS-232 interfaces, but 


the SBC-80/10A also has a teletypewriter current-loop. 


interface. Synchronous/asynchronous mode, data for- 
mat, control-character format, and parity are all 
under program control. So is baud rate on the 80/20 
and 80/20-4. Baud rate is jumper-selectable on the 
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Table 4. Multibus control signals 


Advance-acknowledge signal, used in 
8080A-based systems. It is sent to the 
SBC-80 board by a memory bank in re- | 
sponse to a memory-read command, allow- 
ing the memory to complete the access 
without requiring the CPU to wait. 


Bus clock, used to synchronize bus-control 
circuits on all master boards. It has a period 
of 101.725 ns (9.8304 MHz) and a 30 to 70% 
duty cycle. The signal may be slowed, 
stopped or single-stepped. 


Bus-priority-input signal, used to indicate to 
the master that a higher-priority master 
board wants to use the system bus. When 
brought high, the signal suspends process- 
ing activity and places line drivers of the 
master in a standby mode. 


Bus-busy signal, a bidirectional control line 
| that allows control and monitoring of the 
Multibus in multimaster systems. As an 
output from a bus master, cteates 
the bus is being used by the board. 

prevents all other master boards from oh 
ing control _of the bus. Each master 
monitors as an input to determine 
current Multibus usage status. 


Constant clock, used to Spavide: a 9. 8304- 
MHz clock signal for optional memory and 
1/0 expansion boards. coincides with 

and has a period of 101.725 ns and 
a 30 to 70% duty cycle. 


_ | Initialize signal, used to reset the entire 
system to a known internal state. 


Interrupt input, used to interrupt the proc- 
essor via an externally generated interrupt 
request. 


1/O-read command, a signal generated by 
the master to indicate that the address of 
an input port has been placed on the 
system-address bus and that the data at 
that input port are to be read and placed 
on. the system-data bus. 


|/O-write command, a signal generated by 
the master to indicate that the address of 
an output port has been placed on the 
system-address bus and that the contents 
of the system-data bus are to be output to 
the addressed port. 


Memory- -read command, a signal generated 
by the master that indicates that the ad- 
dress of amemory location has been placed 
on the system-address bus. It specifies that 
the contents of the addressed location are 
= be read and placed on the system-data 

us. 


Memory-write command, a signal gener- 
ated by the master to indicate that the 
address of a memory location has been 
placed on the system-address bus. It causes 
information on the data bus to be written 
into the addressed memory location. 


: Transfer-acknowledge signal, an input sig- 
nal to the master board from an external | 
memory location or I/O port to indicate that 
a specified read or write operation ne been — 
completed. , 
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80/10A CPU board. 

The synchronous and asynchronous nature of the 
serial interface makes it compatible with virtually 
every standard serial data-transmission technique 
used today (including IBM’s Bi-Sync). This allows 
multiple SBC-80 boards to be interconnected as a 
distributed-processing network. The resulting task 
segregation or redundancy (or both) significantly 
improves both system performance and reliability. 

Two jumper-selectable interrupt requests may be 
generated automatically by the serial interface. One 


occurs when a newly received character is ready to 


be loaded into the CPU (receive-channel buffer is full). 
The other occurs when new data are ready to be 
transmitted to the remote device (transmit-data buf- 
fer is empty). aa 

Both the SBC-80/04 and 80/05 provide serial I/O 
capability through the serial input data (SID) and 
serial output data (SOD) functions of the 8085 CPU. 
These functions are controlled by software executing 
the 8085 read-interrupt mask (RIM) and set-interrupt 
mask (SIM) instructions. | 

For systems requiring many serial channels, the 
SBC-534 communications-expansion board provides 
four USART channels with RS-232-C and optically 
isolated current-loop interfaces, programmable inter- 
rupt, timing, baud-rate control, and a Bell 801 Auto- 
Call unit interface. : : "eT 


Expand the system via the Multibus 


The SBC-80 family is gaining not only in popularity 
but in support for its Multibus as more and more 
companies offer SBC-compatible boards. Intel now 
provides high-speed mathematics, RAM, EPROM, 
mass storage, digital I/O, combination memory and 
I/O, serial communications, and analog-I/O expansion 
boards. | | 

For applications requiring fast, high-precision 
number crunching, the SBC-310 math unit acts as an 
intelligent slave to perform floating-point and fixed- 
point mathematics. A processor uses the 310 by 
passing parameters to it along with a command byte 
to select the desired operation from the SBC-310’s 14 
instructions. The repertoire includes 32-bit floating- 
point (single-precision) addition, subtraction, multi- 
plication, division, squaring, square root, com- 
parisons, and tests; 16-bit fixed-point multiply, sub- 
tract, extended divide, and extended compare; and 
conversion from fixed to floating point or vice versa. 

A completed operation. may be signaled either by 

the math unit via an interrupt or by the host 
processor’s polling the “operation complete” flag in the 
unit’s status register. The result may be retrieved at 
this point or left in the 310’s accumulator for further 
use. @ 3 , 
In addition, the 310 provides control circuitry so that 
it may be treated as a “shared resource” among several: 
CPU boards. — re . 2, %, ese 3h 

Two diskette options are available for mass storage. . 
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Table 5, Programmable interrupt 
modes, SBC-80/20-4 


Fully nested Interrupt request line prior- 


ities fixed at O as highest, 7 


as lowest. 
Specific priority 


Equal priority. Each level, af- 
ter receiving service, be- 
comes the lowest priority 
level until next interrupt oc- 
curs. 
System software assigns low- 
est priority level. Priority of 
all other levels based in se- 
quence on this assignment. 
System software examines 
priority-encoded system in- 
terrupt status via interrupt 
status register. 


Characteristic | Sink current (mA) 
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5 VO———— nO INTEL SBC 902 
Ik 


The SBC-201 diskette controller provides full control 
for one or two single-density diskette drives and acts 
as a programmable slave to masters on the Multibus. 
All diskette information is stored in the IBM soft- 
sectored format. For systems. requiring greater 
storage capacity, the SBC-202 provides full control for 
up. to four double-density diskette drives. Thus, 2 
Mbytes of mass storage may be added to SBC-80-based 
systems for each SBC-202 plugged into the bus. 

Digital I/O may be expanded using any of three Intel 
boards. The SBC-519 provides 72 programmable par- 
allel I/O lines as well as interrupt handling and a real- 
time clock. 

The 519’s clock can interrupt the appropriate CPU 
periodically so that the CPU can monitor system-I/O 
status. High-speed. I/O events. can. gain the CPU’s 
attention via interrupts. The SBC-517 combination 
I/O board and the SBC-104, 108 and 116 combination 
memory and I/O boards offer 48 programmable par- 
allel lines, a, full. RS-232 USART serial channel, 
interrupt handling and a 16-ms real-time clock. The 
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Table 7. RMX-80 routine library — 


RMX/80 module | _ Function — 


Provides basic capabilities (concurrence, priority, and synchroniza- | 
tion/communication) found in all real-time systems. oa es 


‘Nucleus (executive) — 


Provides real-time asynchronous I/O between an operator’s terminal and tasks 
running under the RMX/80 executive, includes a line-edit feature similar to | 

_ that of ISIS-II (Supervisory system on the Intellec development system) and 
type-ahead facility. 


. Terminal handler 


Diskette driver and file management capabilities, allows user to load tasks | } 
into the system and to create, access, and delete files in a real-time 
environment without disrupting normal processing. File formats rere 
with ISIS-Il for both single and double- raenehy systems. 


_ Diskette file systems 


Maintains ‘a pool of free RAM and allocates memory out of the pool upon 


Free space manager / 
. | request from a task; reclaims memory areas when no longer needed. 


Specifically designed for debugging software running under the RMX/80. 
executive; used by linking it to an application program or task. anus it can 
be run directly from the single-board computer’s memory. 


Debugger 


Math handler Provides full control and eaniciuniestion for SBC 310 math board for high- | : 


speed fixed and floating-point math functions. 


Analog interface handler 
boards. 


104, 108 and 116 also hold up to 8 kbytes of EPROM, 


along with 4, 8 or 16 kbytes of RAM, respectively. | 


For systems geared to especially noisy environ- 
ments, the SBC-556 provides 48 optically isolated 1/0 


lines, which are configured as 24 input lines, 16 output . 


lines, and eight programmable-I/O lines. The user 
fixes the optical-isolation characteristics according to 
his. exact system requirements by installing the opto- 
isolators and current-limiting resistors of his choice 
into the board sockets. Input voltages up to 48 V, 
output lines up to 30 V and currents up to 60 mA may 
be interfaced. 

Of course, many more RAM, ROM, communications 


and interface options are available. But for systems 


to come together quickly during development, there 
must be some standardized operating software to 
provide some of the most fundamental system rou- 
tines. | 


System software: the glue ‘that binds 


Where the Multibus provides a standard hardware 
structure, RMX-80, a real-time multitasking executive 
supplies a modular software framework. With 


RMX-80, routines don’t have to be developed for task. 
synchronization, priority resolution and peripheral 


control (printers, terminals, diskettes, etc.). Versions 


s 


Provides real-time control for SBC 711, 724, and 732 agate 1/0 expansion 


are aeaiabie for ‘ie SBC- 80/20, 80/20- 4 and 80/ 10A 
CPU boards. 

Critical projects can be completed rapidly necdane 
RMX-80 provides major portions of the software 
requirements for many real-time systems. For exam- 
ple, the diskette file-extension software of the RMX-80 
program may be linked into the system software. 
Thus, users can immediately have a diskette file 
structure with facilities to open and close files, create: 
and delete files, read or write files sequentially ar 
randomly (read function may be used for initial 
program load, if desired), or allocate file storage 
dynamically on single or double-density diskettes. 

‘The compactness of RMX-80—the entire executive 
resides in 2 kbytes of ROM—reduces memory require- 
ments and eliminates the need for bootstrap-program 
loading. All RMX-80 operations are based on individ- 
ual tasks. A task is a program with unique data and 
stack that operates Bey enn OnOualy with other such 
programs in the system. 

Basically, the RMX-80 is a irae of “standard” 
routines (Table 7), such as an analog-interface handler 
and a terminal handler. Fig. 4 illustrates how to 
develop software by selecting appropriate RMX-80 
modules, then locating and linking them with particu- 


_lar software tasks on an Intellec microcomputer 


development system. In addition, a debugger module 
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5. This possible SBC-80 system configuration uses four 
SBC-80/05s to monitor and control pipeline parameters 


in the RMX-80 speeds real-time system development. 

The executive accesses system resources according 
to task priority, intertask communication, interrupt- 
driven control for standard devices, real-time clock 
control, interrupt handling, and other optional func- 
tions. In all, there are 255 separate task-priority levels, 
and since multiple tasks may share the same level, 
the actual number of tasks is limited only by memory 
size. 


Develop programs with the Intellec 


The Intellec and its ICE-80 and ICE-85 in-circuit 
emulators help minimize the time required to develop 
software and hardware. Standard Intellec stand-alone 
software includes resident macroassemblers for the 
8080A and 8085 CPUs, a text editor, and a system 
monitor/debugger. As a result, programs can be 
assembled, loaded, edited, executed, and debugged. 

ICE diagnostics can significantly reduce program 
development and debug time. Break points may be 
set on user-specified memory-read or write opera- 
tions, I/O read or write operations, or user-defined 
extension parameters. Programs can be single-stepped 
to check operating conditions and performance. 

PL/M-80 is the high-level systems-programming 
language. The optional Intellec-resident PL/M com- 
piler provides the ability to program in this natural, 
algorithmic language, so there is no need to manage 
register usage or to allocate memory. PL/M programs 
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and feed data back to a master controller, an SBC-80/20-4. 
The. master controller sends data back to a host system. 


SBC 20! 
DISKETTE 


6. Expanding the pipeline monitor/controller system is as 
simple as plugging more cards into the Multibus and 
altering the software. By adding another SBC-80/20 to the 
master controller, some local processing can be done and 
a local CRT and high-speed printer can be added as well 
as RAM and diskette-memory space. 


may be linked to assembly-language programs to 
hasten product development further. 

A relocatable macroassembler residing on the In- 
tellec translates symbolic assembly language into 8080 
or 8085 machine code and permits the use of re- 
locatable and linkable object code. With full macro 
capability, similar sections of code needn’t be written 
over and over. 

Intellec options include a diskette operating system, 
ISIS-II, with diskette controller, single or dual diskette 


AFN-01931A 


drives and ISIS-II software. ISIS-II provides all the 
facilities for producing and handling relocatable code, 
including a relocating macroassembler, relocating 
loader and a linker to help link separately comple 
or assembled programs. , 


Apply the SBC boards to real use — 


To get an idea of the SBC 80 family’s capabilities, 
examine the application shown in Fig. 5. In this case, 
a remote control/monitoring section of a pipeline 
supervisory control system grows with increasing 
requirements for additional local throughput and 
processing capability. 

Four SBC-80/05s act as remote pipeline 
monitors/controllers. Each unit monitors various con- 
tact closures (limit switches, relays, etc.) and a hex 
keypad, with a subset of its own I/O lines programmed 
as inputs. Contact debounce is performed in software. 
Other digital I/O lines on each SBC-80/05 act as output 
lines to drive a numeric display and various control 
relay coils. 

Analog-control lines are interfaced with an SBC-732 
combination analog-I/O board. Transducers indicat- 
ing temperature and pressure drive analog inputs, and 
analog outputs drive valves. Flow rate is determined 
in software by manipulating differential pressure 
data available from pressure transducers. 

The four 80/05s are linked serially to a remote 
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with one 


SBC-80/20-4-based data concentrator. An SBC-534 
communications expansion board. provides four 
RS-232-C serial channels, each interfacing directly 
of the four 80/05-based pipeline 
monitor/controllers. The 80/20-4 periodically queries 


each monitor to determine its current status. The 
concentrator also relays control commands from a 


host computer controlling the entire pipeline. The 
80/20-4’s own RS-232-C serial channel provides the. 
interface for this high-speed synchronous link to the 
host CPU. 

The 80/20-4 can contact the host CPU with the Bell 
801 automatic calling-unit interface on the SBC-534. 
The synchronization and control of communication 
between the four 80/05s and the host are handled by 
RMX-80 on the 80/20-4. 

The 80/20-4 system can be expanded to provide local 
processing capability, as shown in Fig. 6. Here, anoth- 
er 80/20 is added as a second master on the Multi- 
bus to provide control for a local CRT and high- 
speed printer, and to provide local processing 


capability. 


An additional 82 kbytes of RAM are furnished by 
an SBC-032 RAM-expansion board. A third master, 
an SBC-202 dual-density diskette controller, can also 
be added to the Multibus, along with two double- 
density diskette drives. Communication between the 


two 80/20s is handled via user-written intermaster — 


message tasks.us 
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FOR MULTIPLE PROCESSOR 
MICROCOMPUTER SYSTEMS 


Design decision factors involved in developing multiple processor 
microcomputer systems include means of minimizing contention for 
system bus utilization. System applications detail the appropriate 
hardware and software considerations as related to single-board 


computers in a multimaster bus structure 
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Li integrated circuit technology has reduced 
the cost of central processors. to such a low level that 
the previously avoided concept of applying multiple 
processors to meet system performance requirements has 
now become an attractive and viable alternative. Several 
key benefits accrue from such an approach. In addition 
to enhanced system performance (throughput), improved 


system reliability, and improved system realtime re- 


sponse, modular system expansion capabilities may be 
realized. Although designing such systems “from 


scratch” with microprocessor component families can ~ 


be a complex system design task with many subtle pit- 
falls which can inhibit efficient system operation, the 
advent of second generation single-board computers, 
such as the Intel® SBC 80/05 and 80/20, has allowed 
multiple processor microcomputer systems to become 
off-the-shelf products. 


Motivation and Design Concepts 


Discussion of the benefits of multiple processor structures 
in system applications will provide an understanding of 
the motivation for this implementation approach in sys- 
tem design. A primary objective addressed. through 
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multiple processor approaches is enhanced system per- 
formance and throughput. Enhanced performance is 
achieved through partitioning of overall system functions 
into tasks that each of several processors can handle | 
individually. 

In general, as the number of individual tasks any 
given processor must handle is reduced, that processor’s 
response time to new requests for service will be reduced. 
A well planned multiple processor bus structure will 
allow new processors to be added to the system in 
modular fashion. When new system functions (ie, more 


peripherals) are. added, more processing power can be 


applied to. handle them without impacting existing pro- 
cessor (master) task partitioning. 

As used here, a “master” is any element existing on the 
system bus that may take control of the bus (ie, assert 
address and control. lines). Typical examples include 
processors and direct memory access (DMA) controllers 
that address memory and input/output (1/0) locations 
resident on the bus. “Slave” elements include passive 
functions ‘on the bus, such as memory or non-DMA I/O 
interfaces. Note that although slaves may possess intelli- 
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Fig 1 Multiple processor bus structure. Dual onboard/offboard structure of MULTIBUS allows each master to use its 
own memory and !/O without utilizing common system bus (a). Only when a master requires access to common mem- 
ory or I/O does it use the bus (b). Note that other masters may continue onboard operations simultaneously 
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Fig 2 SBC 80/05 block diagram. 
SBC 80/05 is a full microcom- 
puter on a single PC board. It 
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gence (eg, an onboard processor), they are not bus 


‘“‘masters” unless they can control the system bus. 


Hardware Considerations 


Hardware considerations must be thoroughly evaluated 
in any multiple processor bus structure. These factors 
are described in detail around a specific implementation 
of such a structure, the Intel* mMuLTIBUS™, which sup- 


ports multiple processor systems with its multi-master. 


bus structure. 


Bus Architecture 


One architectural option open to the system designer is 
that of a multiple master/single bus structure. Under 
this partitioning, every master utilizes the common bus 
data path to fetch instructions or data from memory, 
read data from input devices, or write data to output 
devices or memory. Therefore, the common system bus 
rapidly becomes the bottleneck for overall system 
throughput, and fast DMA transfers can easily approach 
the full bandwidth of the bus during block transfers so 
that all other masters must idle for extended periods. 


RS-232-C 
COMPATIBLE 
DEVICE , 


CONTROL “] 
INTERFACE | 
* 


CONTROL BUS 


© SERIAL 
DATA 
INTERFACE 


Such performance constraints can severely limit total 
system performance. : 

System bus utilization may be minimized through 
implementation of an alternate dual-bus structure as‘ 
shown in Fig 1. Each processor-based master within the 
system retains its own local memory and. 1/o that it 
utilizes for most operations. Such local operations occur 


totally on the individual board and do not require the 


system bus.. This greatly reduces the service request. 
frequency by each master requiring use of the system bus. 
Such a dual-bus structure is implemented on the SBC 
80/05 and 80/20 single-board computers, as shown in 
Figs 2 and 3, respectively, with the multi-master system 
bus (MULTIBUS) .)-?. 
- Access to the system bus is requested only when a 
global (resident on the bus and accessible by multiple 
masters) memory location or 1/0 device is referenced 
during an instruction execution cycle. Local/global (on- 
board/offboard) distinction is defined through the value 
of the physical address referenced. If it lies within the 
address range of onboard memory or 1/0, no bus request. 
is made. Only when the address references a global 


Intel® and mu.Ltisus™ are trademarks of Intel Corp, Santa Clara,- 
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Fig 3 SBC 80/20-4 block diagram. SBC 80/ 20-4, also a full microcomputer on a single PC board, provides 8080A-2 CPU, 
4k bytes of RAM, up to 8k bytes of EPROM/ROM, 48 programmable I/O lines, three interval timers, full RS-232-C serial 
port, 8-level priority interrupt logic, and MULTIBUS multimaster control logic | 
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memory or 1/0 location, is a system bus request initiated. 
If no other master is currently utilizing the bus, this 
“new” master will be granted access immediately. How- 
ever, this new master must wait if another master is 
currently utilizing the system bus. It continues to monitor 
the status of the system bus to determine when its cur- 
rent cycle may be completed. Thus, the MULTIBUS must 
provide a method for masters to determine whether or 
not another master is currently utilizing it. 

Other masters may also simultaneously request the 
system bus. Arbitration must then be performed to re- 
solve this multiple contention for the system bus. The 
MULTIBUS structure provides this arbitration in one of 
two techniques: serial (daisy chain) or parallel (en- 
coded). The structure consists of four control lines that 
are synchronized by the common bus clock. These four 
control lines and the bus clock are active low. This is 
represented by the slash (/) character after each signal 
mnemonic. Control lines are as follows: 


Bus Clock (BCLK/) —The negative edge of BCLK/ is 
used to synchronize bus arbitration. BCLK/ may be asyn- 
chronous to all cpu clocks, and it has a 100-ns minimum 
period. BCLK/ may be slowed, stopped, or single- 
stepped for debugging. 


Bus Priority In Signal (BPRN/)—lIndicates to a par- 
ticular master that no higher priority master is request- 
ing use of the system bus. 

Bus Priority Out Signal (BPRO/)—Used with serial bus 
priority resolution scheme. BPRO/ is passed to BPRN/ 
input of master with next lower bus priority. 


Bus Busy Signal (BUSY/)—Driven by bus master cur- 
rently in control of MULTIBUS to indicate that bus is 
currently in use. BUSY/prevents all other masters from 
gaining control of bus. 


Bus Request Signal (BREQ/)—Used with parallel bus 
priority network to indicate that a particular master re- 
quires use of the bus for one or more data transfers. 


ah 
\: ay ie 


Serial (Daisy-Chain) Bus Arbitration 


In a serially arbitrated MULTIBUS system (Fig 4) re- 
quests for system bus utilization are ordered by priority 
on the basis of bus location. Each master on the bus 
notifies the next lower priority master when it needs to 
use the bus for a data transfer, and it monitors the bus 
request status of the next higher priority master. Thus 
the masters pass bus requests along from one to the next 
in a daisy-chain fashion. 

The highest priority master (Master 1) in the system 
will always receive access to the system bus when it 
requires it. There is no higher priority master to inhibit 
its bus requests, and its bus priority input line (BPRN/) 
is thus permanently enabled. 

Masters operate asynchronously on the MULTIBUS. A 
master may thus be in the middle of a bus operation 
when a higher priority master requests the bus. Ob- 
viously, interruption of such an in-process cycle must 
not be allowed. The mechanism for avoiding such 
erroneous operation is the BUSY/ line. Upon being 
notified that access to the bus is possible, the master 
examines BUSY/. If this control line is inactive, the 
master will assert it, and complete its bus operation. 
If BUSY/ is already active, another master is currently 
using the bus. In this case, the master will examine 
BUSY/ upon every falling edge of BCLK/, typically 
once every 100 ns, until it becomes inactive. When 
BUSY /returns to its inactive state, the master will assert 
it, then complete its operation. The BUSY/line then in- 
hibits higher priority masters from destroying a bus 
transfer cycle that may be already in progress. 

The BUSY/ line is also controlled by a bus lock 
function on the SBC 80/05 and 80/20. This function 
allows a master, which currently has control of the bus, 
to retain control by independently asserting the BUSY/ 
line until it issues an unlock command that releases 
BUSY/. This permits a bus master to obtain exclusive 
control of the system bus for critical system functions, 


Fig 4 Serial bus arbitration. When any master 
requires use of MULTIBUS in serial (daisy-chain) 
priority mode, its BPRO/ line inhibits lower prior- 
ity masters from system bus utilization. BUSY/ 
line is used to ensure that in-process operations 
of lower priority masters are not destroyed by 
asynchronous bus requests of higher priority 
masters 
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such as high speed memory or 1/o data transfers and 
critical read-modify-write operations. With BUSY/ 
asserted in this way, all other masters will find the bus 
“In use” when they attempt to access it. Whereas system 
bus transfers normally take place on an interleaved basis 
(bus arbitration performed for each cycle), this bus 
lock function permits fast multiple-word transfers, when 
needed. | 
Two basic parameters determine the number of masters 
that can coexist on the system bus in serial bus arbitra- 
tion mode. These are the BCLK/ cycle time and the 
BPRN/ to BPRO/ propagation delay of bus masters. 
Masters may be added to a system as long as the cumula- 
tive BPRN/ to BPRO/ propagation delay is such that the 
lowest priority master will always have its BPRN/ line 
driven inactive before the next BCLK/ falling edge after 
the highest priority master requests the bus. This worst- 
case timing condition is met as long as the following 
relationship is satisfied. . 


N-l . 

> (tpprn-pero) i < taeix — tsh 

i=l 

where > 

(tarprn-prro): = Propagation delay for master i 


tnctx = Bus clock (BCLK) cycle time (period) 
tsn = Allowance for bus setup and hold times 
N = Number of bus masters 


Using serial bus arbitration and SBC 80 onboard 
clocks, up to three masters may coexist on the system 
bus. This number can easily be extended, if desired, by 
generating a BCLK with a longer cycle. The SBC 80/05 
and 80/20 provide a jumper option which allows the 
onboard BCLK/ to be disabled. This allows the system 
designer to generate BCLK/ externally. | 


Parallel (Hardware-Encoded] Bus Arbitration 


The parallel bus arbitration technique resolves system 
bus master priorities using external hardware. The 
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parallel multimaster control line (BREQ/) comes into 
force in this case. Each master asserts BREQ/ when it 
requires access to the system bus. These lines are fed 
to a 2-chip parallel priority network. As with serial 
priority resolution, BPRN/ acts as the bus access enable 
input to each master. As Fig 5 illustrates, up to eight 
master priority levels are encoded by a 74148 priority 
encoder to a 3-bit code representing the highest priority 
master currently requesting the system bus. This code 
drives the 8205 3-to-8 decoder which asserts the proper 
BPRN/ line low to grant bus access to the highest 
priority master. The 74148/8205 propagation delay is 
less than 40 ns, easily fast enough to allow eight masters 
to coexist in this configuration utilizing a BCLK/ with 
a 100-ns period. . | 

Systems requiring up to 16 masters may implement bus 
arbitration by utilizing two 74148 priority encoders and 
two 8205 decoders to provide a 16-level hardware pri- 
ority network. The actual number of bus masters feasible 
on the system bus will also depend on bus drive/loading 
considerations. Even under this consideration, systems 
containing up to 16 masters are feasible. 

Thus, single-board computer masters, in conjunction 
with the MULTIBUs control structure, provide off-the-shelf 
hardware solutions for the development of efficient multi- 
ple processor microcomputer systems. In addition to this 
hardware capability, the system designer needs to con- 
sider several software design issues. 


Software Considerations 


Several software operations, such as mutual exclusion, 
communication, and synchronization, are essential to 
proper multiple processor system operation. The 
MULTIBUS/SBC 80 functions that enable these software 
operations are examined. 


Mutual Exclusion 


In a multiple processor microcomputer system, there are 


Fig 5 Parallel bus arbitration. Under parallel bus 
arbitration structure, multiple requests for access to 
the MULTIBUS are determined by 2-chip hardware 
priority network. When simultaneous multiple bus re- 
quests occur, only highest priority master has its bus 
grant (BPRN/) line asserted. BUSY/ line inhibits other 
masters from interfering with system bus cycles in 
progress 
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usually many resources that are shared by the processors. 
Such shared resources include common memory and 
peripherals. A properly functioning system must provide 
a mechanism to guarantee that asynchronous access to 
those resources is controlled in order to protect data 
from simultaneous change by two or more processors. 
Thus, some form of mutual exclusion must be provided 
to enable one processor to lock out access of a shared 
resource by other processors when it is in a critical 
section. A critical section is a code segment that once 
begun must complete execution before it, or another 
critical section that accesses the same shared resource, 
can be executed. 

A Boolean variable can be used to indicate whether 
a processor is currently in a particular critical section 
(true) or not (false). Testing and setting this variable 
also presents a critical section. This function must be 
performed as a single indivisible operation; if it is not, 
two or more processors may test the variable simul- 
taneously and then each set it, allowing them to enter 
the critical section at the same time. Such simultaneous 
entry would destroy the integrity of data and control 
parameters in global memory or cause erroneous double 
initialization of a global peripheral controller. 

Mutual exclusion can be implemented as a software 
function alone, as described by Dijkstra*, for n proces- 
sors operating in parallel. The SBC 80/05 and 80/20 
bus lock function mentioned earlier provides a means 
for using program control to simplify mutual exclusion. 
While the system bus is locked, the master can perform 
the indivisible test and set operation on the Boolean 
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variable used to control access to a critical section with- 
out intervention from other masters. 


Communication 


Communication is an essential function that allows a 
program executing on one processor to send or receive 
data from a program executing on another processor. 
Typically, two processors communicate through buffer 
storage in common memory. One program, called a 
producer, adds data to buffer storage; another, called a 
consumer, removes information from buffer storage. 

In a typical application, one master may produce 
buffers of data that are to be consumed by a program 
executing on another master that services an output 
device. Communication through buffer storage requires 
the operations of adding to and taking from buffers. 
These operations constitute critical sections that can be 
controlled by providing mutual exclusion around the 
buffer manipulation operations. 


Synchronization 


At times there is a need for one master to send a syn- 
chronization signal to another. In a sense, synchronization 
is a special case of communication during which no 
data is transferred. Rather, the act of signaling is used 
to ‘‘wake up” a program executing on another master. 
A program may “‘sleep,” by waiting for a synchronizing 
signal, until it receives a wake-up signal that enables 
it to continue execution. Manipulation of synchronization 
signals requires mutual exclusion. 


SBC 80/20 Fig 6 Multiple processor 


communication application. 
Multiple processors may be 
utilized to increase throughput 
in system requiring several 
high speed serial channels. 
SBC 80/05 single-board com- 
puter controls four RS-232-C 
or 20-mA serial channels _in- 
terfaced to system’ through 
SBC 534 communication ex- 
pansion board. Second single 
board computer (SBC 80/20) 
retrieves data records con- 
structed by SBC 80/05 and 
performs further processing 
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System Initialization : 


In a microcomputer system that has multiple processors 
sharing a common system bus, a system initialization 
mechanism must be designed to set up the variables that 
control. access to the shared resources. All single-board 
computers on the MULTIBUs begin execution simulta- 
neously following a system reset. The bus lock function 
of the computers can be used by one specifically desig- 
nated master to lock the bus immediately upon system 
reset and to perform system initialization for common 
resources before. any other master attempts to access 
them. Since a locked bus has no effect on a single-board 
computer that is executing out of its local memory and 
using its local 1/0, normal initialization by each. processor 
can proceed while the shared resource initialization takes 
place. 


Multiprocessor 
Applications 


Two applications that are well suited to multiple pro- 
cessor microcomputer systems are examined. The first 
provides increased throughput, and the second allows 
shared resources. Bed. | 


Increased Throughput 


Consider a system that is controlling multiple high speed 
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serial communication channels in addition to other data 
processing activities. In this case, multiple processors 
may be utilized to increase system throughput. Such a 
system with four full-duplex serial channels operating 
at 4800 baud could produce interrupts every 250 us. 
Interrupts at that frequency in a single master system 
would leave little time for other processing activities. 
In a multiple processor. approach, one processor can be 
used to handle the interrupts from the serial channels, 
accumulate data into records, and then provide those 
records to another processor by placing them in com- 
mon memory. The second processor is not burdened 
with the overhead of handling each character on an 
interrupt-driven basis, instead it is sent entire records 
of data available for further processing. _ 

As shown in Fig 6, this application can be handled 
on the MULTIBUS with four boards. The SBC 80/05 
single-board computer is used to service the communi- 
cation board and prepare the data records. A 4-channel 
serial communication board (SBC 534) is used to pro- 
vide the hardware interface for four serial communica- 
tion channels. The SBC 80/20 single-board computer is 
used to process data records prepared by the SBC 80/05. 
Common memory is provided by the SBC 016 16k 
random-access memory (RAM). 

Application of multiple processors to this problem 
requires communication through buffer storage. Two 
primitive operations, introduced by Dijkstra*, can be 
used to simplify. the communication and synchronization 
between the masters. These primitives, designated P and 
V, operate on non-negative integer variables called 
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semaphores. The V procedure increments the sema- 
phore (S) in a single indivisible operation. To make 
certain that fetch, increment, and store are not inter- 
rupted by another processor, the bus is locked during 
the operation. 

Procedures for P and V primitive operations can be 
implemented in PL/M® as follows: 


V: 
PROCEDURE (S$ADR) ; 
DECLARE S BASED S$ADR BYTE; 
OUTPUT (BUS$LOCK) = LOCK; /* Lock Muttibus */ 
S=S+l; /* Increment semaphore */ 
OUTPUT (BUS$LOCK) = UNLOCK; /* Unlock Muttisus */ 
END V; 


The P procedure loops in a busy wait until S is greater 
than zero, at which time it decrements S. The act of 
fetching, testing, decrementing, and storing S is also an 
indivisible operation. Note that if several masters with 
different speeds are in a busy wait on the same sema- 
phore, the solution presented may not be “fair” to the 
lower speed processor; that is, the lower speed processor 
would test the semaphore less frequently, resulting in 
an unfair advantage for higher speed processors. 
Implementation of a procedure for the P primitive is 
shown in the following PL/M code. 
P 


" PROCEDURE(S$ADR) : 
DECLARE S BASED S$ADR BYTE; 


DO FOREVER: 
IF S > 0 THEN /* Test semaphore */ 
DO; 
OUTPUT (BUS$LOCK) = LOCK; /* Lock MuLTiBUS */ 
IF S > 0 THEN /* Retest semaphore * / 
—DO; 
S=S-1; /* Decrement semaphore */ 


OUTPUT (BUS$LOCK) = UNLOCK; /* Unlock muttisus */ 


RETURN; /* Exit from P procedure * / 
END; 
OUTPUT (BUS$LOCK) = UNLOCK; /* Unlock MuLtisus */ 
END; /* and continue testing */ 
END; 
END P; 


It is important to observe in the program listing that S 
is tested prior to issuing a bus lock. This initial test 
avoids continuous locking and unlocking of the system 
bus while looping in a busy wait. The second test is 
required because another processor could also have found 
S greater than zero and tried to enter the critical section 
at the same time. 

With the P and V operations, semaphores can be used 
as resource counters in the buffer manipulation required 
for communication between the SBC 80/05 and 80/20. 
For example, a consumer program can use the P oper- 
ation to decrement the number of full buffers and a V 
operation to increment the number of empty buffers. 
In a similar fashion, a producer program can use the 
P operation to decrement the number of empty buffers 
nd a V operation to increment the number of full 
buffers. In addition to full and empty buffer counters, 
it is necessary to maintain linked lists pointing to actual 
full and empty buffers. A semaphore can be used to 
provide mutual exclusion around the manipulation of 
the linked lists. In the example that follows, three 
variables (FULL, EMPTY, and SEMA) are used to imple- 
ment these functions. The two PL/M programs illustrate 
consumer and producer code segments, respectively. 
Note that the consumer performs initialization because 
it accesses the semaphores prior to the producer. 
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CONSUMER: 
DECLARE EMPTY BYTE EXTERNAL; 
FULL BYTE EXTERNAL; 
SEMA BYTE EXTERNAL; 
OUTPUT (BUS$LOCK) = LOCK; 
EMPTY = NUMB$BUFFERS; 
FULL = 0; 
SEMA = 1; 
OUTPUT(BUS$LOCK) = UNLOCK; 
DO FOREVER; 
CALL P(FULL) ; /* Decrement full buffer */ 
CALL P(SEMA); /* semaphore */ 
/* Decrement mutual exclusion * / 
/* semaphore */ 


/* Number of empty buffers */ 
/* Number of full buffers */ 
/* Binary semaphore */ 

/* Lock muLtisus */ 

/* Initialize semaphores */ 


/* Unlock MuLtisus */ 


(Take data from buffer and 
place it in local memory, 
move buffer from full to 
empty linked list) 


/* Increment mutual exclusion */ 
/* semaphore */ 

/* Increment empty buffer */ 

/* semaphore */ 


CALL V(SEMA) ; 
CALL V(EMPTY) ; 


(Process the data) 


END; 
END CONSUMER; 
PRODUCER: 
DECLARE (EMPTY, FULL, SEMA) BYTE EXTERNAL; 
DO FOREVER; 


(Prepare data in local 
memory ) 


/* Decrement empty buffer semaphore */ 
/* Decrement mutual exclusion */ 
/* semaphore */ 


CALL P(EMPTY) ; 
CALL P(SEMA) ; 


(Place data in a buffer, - 
move buffer from empty 
to full linked list) 


CALL V(SEMA) ; /* Increment mutual exclusion * / 
CALL V(FULL) ; /* semaphore */ 


/* Increment full buffer semaphore */ 
END; 
END PRODUCER; 


Shared Resources 


Another typical application for a multiple processor 
microcomputer system would be to allow sharing of a 
resource by two processors. For example, consider two 
independent processors that have a need for high speed 
mathematical functions. Although it may not be possible 
to justify a high speed math module for each system, 
such a module might be justified if it were to be shared 
by both processors. A multiple processor microcomputer 
system could provide the capability to allow both pro- 
cessors to share the math module and not interfere with 
their otherwise unrelated functions. 

This application (illustrated in Fig 7) could be 
handled with four boards. The SBC 80/05 single-board 
computer is used to perform various data processing 
functions requiring high speed floating-point arithmetic. 
The SBC 80/20 single-board computer controls a process 
where high speed numeric computations are required. 
High speed floating-point mathematics functions for 
both single-board computers are performed by an SBC 
310 high speed math unit. SBC 116 combination memory 
and 1/o board provides 16k RAM, 8k electrically pro- 
grammable read-only memory (EPROM), 48 parallel 
1/o lines, and an RS-232-C serial port. 
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The problem to. be solved in this. application ‘is: St6 
ensure that only one processor has access tothe shared 
math module: resource at one’ time. Thus, mutual ex- 
clusion must be provided to control the access to the 
resource. The following PL/M function returns’) TRUE 
if access to a critical section, used to implement the 
mutual exclusion, has been granted. 


ENTER$CRITICAL$SECTION: 
PROCEDURE (FLAG$ADR) BYTE; 
DECLARE FLAG BASED FLAG$ADR BYTE; 
DECLARE ACCESS BYTE; 


IF FLAG = BUSY THEN 
RETURN FALSE; 

ACCESS = FALSE; 

OUTPUT (BUS$LOCK) = LOCK; 

IF FLAG = NOT BUSY THEN 


/* Test flag */ 
/* Return false if busy */ 


/* Lock MuULTIBUS */ 
/* Retest flag */ 


DO; . 
FLAG = BUSY; .. /* Set flag busy */ 
ACCESS = = TRUE; /* and access TRUE */ 
END; 


/* Unlock MULTiIBUsS */ 
/* Return either TRUE or */ 
/* FALSE access */ 


OUTPUT (BUS$LOCK) = UNLOCK; 
RETURN ACCESS; 


END ENTERS$CRITICAL$SECTION ; 


This PL/M function first tests the flag for the busy 
condition before issuing a busy lock. As in the P pro- 
cedure described earlier, this initial test avoids con- 
tinuous locking and unlocking of the MULTIBUS while a 
busy wait is being executed. The following procedure 
performs a busy wait operation on the flag used to 
control access to a critical section. ae 


BUSY$WAIT: - 
PROCEDURE (FLAGSADR) ; ; 


DO WHILE NOT ENTER$CRITICAL$SECTION (FLAG$ADR) ; 
END; 


END BUSY$WAIT; 


Typical code segments illustrating the use of these pro- 
cedures follow. 


DECLARE MATH$BD$FLAG BOOLEAN EXTERNAL;  /* Flag must be */ 
/* initialized */ 


MATHS$§BD$FLAG = NOT BUSY; 


/* Here we wait until */ 


CALL BUSY$WAIT (.MATH$BD$FLAG) ; 


ee /* we have access */ 


(Process math functions) 
MATHSBD$FLAG = NOT BUSY; 


. /* Set flag not busy */ 


I We auld: also test. and thes de: some saber: wir 

/* — processing if the math module is busy */' 
IF ENTERSCRITICAL$SECTION (. MATHSBDSFLAG) 
.THEN DO; ar _ 


(Process math functions) ©" 
MATHSBDIEE ACS : NOT BUSY; 


: END; 
ELSE DO; 


: y* Set flag not busy */ | 


ae (Something else) 


| “END; 


Conclusions | 


The : motivations - for. implementing. multiple processor: 
Microcomputer systems include. enhanced performance 


and throughput. When the appropriate ‘hardware/soft- 
ware. design. considerations are made, modularity’ is: 
easily achieved. Hardware solutions: to. many problems 
are provided. by means of a ‘MULTIBUS structure and. 
SBC 80 single-board computers that have multimaster 
capability. Through control of MULTIBUS functions, the 
software designer can perform multiple processor com- 
munication, synchronization, and mutual exclusion. 

Even with these significant steps toward the simplifi- 
cation of multiple processor microcomputer systems, the 
design of such. systems remains. a complex software/ 
hardware design task. The future trend of multiple 
processor microcomputer systems will be to simplify the 
software tasks of implementing communications, . syn-. 
chronization, and mutual exclusion. These functions, 
could be performed in varying degrees by additional 
hardware bus functions. | 

Potential rewards for a multiple processor architecture 
include enhanced system throughput, improved real-time 
response, modular system expansion, and improved sys- 
tem reliability. These benefits will pressure the tech- 
nology of parallel processing to include microcomputers 
in an increasing number of computer applications. 
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Technology 


Triple-bus architecture lets a 
single-board microcomputer’s CPU operate at full speed 
while other system components share the main memory. 


The introduction of Intel’s iSBC 80/30 marks the 
beginning of the third generation of single board 


computer architecture. Two features separate the new | 
microcomputer from second-generation single-board » 


uCs. The major one is a triple-bus architecture that 
supports a dual-port memory. As a result, the on- 
board CPU does not tie up the main system bus (Intel’s 


Multibus) when using the memory. Moreover, with. 


two ports, the memory becomes a global resource, 


accessible via the three buses from the on-board 8085A. 


CPU as well as from remote CPUs and other external 
devices in multimaster schemes. 

In addition, the 80/30 contains two microprocessors: 
an 8085A acting as the master CPU and an 8041 single- 
chip microprocessor acting as a slave, or r intelligent- 
1/0, processor. 


Jim Johnson, Project Leader, Craig Kinnie, Project Man- 
ager, and Mike Maerz, Marketing Manager, Intel Ceres 
Santa Clara, CA 95051. 


Reprinted by Permission: Electronic Design, 1978. 


To appreciate the benefits of the 80/30’s triple-bus, 
dual-port memory architecture, examine the following 
problem. Now that fully one fourth (16-kbytes) of the 


available memory space in a 64-kbyte uC system can 


reside on a single-board uC, the CPU must share these 
16-kbytes with other system components, such as 


direct-memory-access devices, discs and other proces- 


sors. What’s the best solution—especially when, in 
many applications, 16-kbytes is all the memory that’s 


required by the whole system? 


Alternatives have problems 

The ‘most straightforward way is a split-bus 
architecture, in which both the CPU and the system 
have equal access to the memory (Fig. 1a). While the 
system bus will be able to handle memory access 
efficiently from devices tied to it, it will be tied up 
by the CPU—so external operations not related to 
memory accesses will be hindered. 
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SPLIT BUS: 


SYSTEM 


DUAL BUS: 


SYSTEM 
BUS 


1. Microcomputer-bus organizations takes several forms: 
In a split-bus approach (a) the CPU and system have equal 
access to memory, but the CPU ties up the system bus; 
in a single-bus (b), the CPU encounters extra delays in 


A single-bus approach (Fig. 1b) is hampered by 
buffer and bus-intervention delays which limit the 
CPU’s performance. And dual-bus architecture (Fig. 
1c), while granting the CPU exclusive access, does not 
allow other bus masters access to the memory. Also 
dual-bus suffers from buffer delays. 

A triple-bus, dual-port architecture (Fig. 1d) pro- 
vides the benefit of both single and dual-bus architec- 
tures: total system access and exclusive access by the 
CPU. But it also has its disadvantages: Dual-port 
architecture requires many buffers as well as access- 
arbitration logic. However, 20-pin octal buffers in- 
troduced by several manufacturers don’t take up 
nearly as much board space or cost as much as 
equivalent standard buffers. Since the octal buffers 
come in unidirectional or bidirectional forms—and at 
nearly the same cost—the three-bus approach used 
on the 80/30 actually takes only as many packages 
as the split-bus approach. 

Access arbitration is solved in the 80/30 with cycle 
status signals from the 8085A CPU. Instead of provid- 
ing equal access to the RAM from both the CPU and 
the system, the arbitration logic is designed to favor 
the CPU. By assigning the default state of the arbiter 
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SINGLE BUS: 


SYSTEM 
BUS 


TRIPLE BUS: 


BUS 
ARBITRATION 
LOGIC 


SYSTEM 
BUS 


using the system bus. A dual-bus structure (c) also has 
buffer delays, and no system access to on-board memory. 
But a triple-bus (d) avoids all these problems, MOMS 
total system access to memory. 


to the CPU, the logic anticipates a CPU memory access 
and reserves the memory until the cycle is complete. 
In addition, if an on-board CPU access is imminent, 
a reservation signal derived from the 8085A CPU 
status signals, the ALE (address latch enable), the 
address, and the cycle status signals (SO, SI, IO/M) 
will hold off bus contention. As a result, the CPU can 
operate at full speed without tying up the system bus. 
Of course, this extra CPU performance cuts into the 
rest of the system’s memory-access time. However, 
the penalty imposed by the arbiter is less than 200 
ns—less than the time it would take a DMA device 
to regain control of the bus in the split-bus approach, 
where access must be interleaved. | 


A bus hierarchy 


The three buses in the 80/30 hierarchy (Fig. 2) are 
an on-board bus, a dual-port (DP) bus and the Multi- 
bus (system bus). Innermost is the on-board bus, 
which connects the 8085A, all on-board I/O peripher- 
als and ROM. The next bus in the hierarchy, the dual- 
port connects a dual-port controller, 16-kbytes of 
dynamic RAM and a dynamic RAM controller. The 
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2. The full 80/30 one-board microcomputer is organized 
around its three buses: on board, dual-port, and the 
external-system Multibus. The main CPU, an 8085A, runs 


iSBC 201 
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ADDRESSES. | PORT ADDRESSES | PORT 
16K-32K BUS 16K -32K BUS 
RAM RAM 
ADDRESSES ADDRESSES 
32 K-48K 48K-64K 
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3. The microcomputer’s on-board memory may be ad- 
dressed independently by the on-board central processor 
and Multibus bus masters to increase the efficiency of 
usage of the total available memory space. . 
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at 2.76 MHz, while an 8041A one-chip microprocessor 
serves as a peripheral controller or slave processor, 
running with a 2.6-ms cycle time. 


outermost bus, the Multibus, offers modules that 
permit either the expansion or addition of system 
resources. . in | | 

With the on-board. bus, the 8085A communicates 
with its on-board I/O and ROM (or PROM, if desirable) 
and the dual-port bus. Since the on-board bus permits 
access to the I/O and ROM only from the 8085<A, all 
I/O and ROM (up to 8-kbytes are the 8085A’s private 
property). And as a result, the 80/30 can operate on 
its on-board bus while another Multibus master uses 
the Multibus,.accessing data from the board’s dual- 
port RAM without reducing processor speed. 

The dual-port (DP) bus contains 16-k of read/write 
memory, implemented with Intel’s 2117 16-kbyte 
dynamic RAM and the 8202 dynamic RAM controller 
(DRC). The DRC interfaces the DP bus to the 16- 
kbytes of dynamic RAM, and provides an almost 
static-RAM type interface. It provides the system with 


- multiplexed addresses, address strobes, and refresh 


control to the RAM, as well as refresh/access arbi- 
tration and acknowledges. | et a 
The RAM on this bus can be accessed from either 
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the 8085A on the 80/30 or the Multibus. The DP 
controller arbitrates the RAM requests and performs 
the bus exchanges. 

The DP controller always leaves the DP bus under 
the control of the 8085A when it is not in use. This 
permits the 8085A to operate at maximum processor 
speed when controlling the bus, since there isn’t any 
bus-exchange overhead. When the Multibus requests 
access to the DP RAM, the DP controller transfers 
control of the DP bus to the multibus, as soon as the 
DP bus is not busy. Once the Multibus transfer is 
complete, the DP bus is returned to the 8085A. 


Multiple communication 


The DP controller has two independent address 
decoders—one for decoding Multibus requests, the 
other for 80/30 requests. This not only permits the 
address space of the memory to be located in two 
different parts of memory (Fig. 3), it enables several 
80/30s to talk to each other over the Multibus, while 
sharing the same on-board address as seen by the 
8085A. Thus, one program can be loaded in any 80/30 
without relinking and relocating the software for 
execution. 

Each bus can communicate either within itself, or 
with the adjacent bus. Thus, the on-board bus cannot 
communicate directly with the multibus. However, 
when the CPU makes a bus request, the on-board and 
dual-port buses simultaneously determine if they can 
fulfill it. If the on-board bus can acknowledge the 
request, it does so, and the DP bus control is not 
required to determine if the DP bus can acknowledge 
the request. If the DP bus, not the on-board, can 
acknowledge the request, it does so, and the controller 
then lets the CPU use the bus. Thereafter, the RAM 
controller completes the operation and generates an 
acknowledge signal. , 

If neither the on-board nor DP bus can fill the bill, 
the Multibus is solicited by the CPU. Since a bus can 
only communicate with an adjacent bus, the on-board 
bus must request the DP bus to communicate with 
the Multibus via the DP controller. The on-board bus 
will retake control of the DP bus only after the request 
to use the Multibus is granted. This prevents lockout 
problems with the DP bus, where the CPU requests 
the Multibus when it is controlled by another bus 
master accessing the DP RAM. 

How the 80/30 performs is directly related to how 
many buses it must use to complete a requested 
operation. The on-board bus always operates at max- 
imum processor speed. The DP bus operates at max- 


imum only if it hasn’t been busy and a memory refresh 


cycle was not in process. The processor speed when 
the Multibus is used depends on bus overhead involved 
and the type of module requested. | 

The 80/30 boasts more than a three-bus architec- 
ture. For one thing, its I/O is designed to interface 
to a wide variety of external devices, including 
switches, motor drives, bistable sensors, displays, 
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The 80/30 in brief 


The iSBC 80/30 uses the latest LSI components to 
obtain the highest performance of any Intel single- 
board computer. Built on a 6.75 X 12-in. board, it 
contains the following features: 

w 8085A central processor operating at 2.76 MHz. 

a 16-kbytes of dual-port RAM using Intel’s new 16- 
kbyte dynamic RAMs and 8202 dynamic RAM con- 
troller. 

a Sockets for 2, 4 or 8-kbytes of ROM using Intel’s 
2758, 2708, 2716, or 2332 EPROMs or ROM re- 
placements. 

« A socket for Intel’s 8041A/8741A universal pe- 
ripheral interface (UPI) having 18 software-con- 
figurable I/O lines with sockets for drivers/termi- 
nators. 

a A programmable serial-communication channel 
with RS-232 interface and programmable baud rate. 

«» Multibus control logic which allows up to 16 
masters to share the system bus. 

a 12 vectored priority interrupts. 

a Two programmable 16-bit BCD or binary internal 
timers. 


keyboards, printers, teletypewriters, communicator 
modems, cassettes and other computers. This ver- 
satility is provided with LSI programmable devices 
such as Intel’s 8255 programmable parallel I/O device, 
8251A programmable communication channel, 8253 
interval timer, 8259 interrupt controller, and 
8041A/8741A universal peripheral interface (UPI). 


The slave processor 


The ability to interface this wide variety of external 
devices is facilitated by the 8041A/8741A UPI (Fig. 
4), which can be added to the 80/30. The UPI is a 
complete single-chip microcomputer which acts as a 
peripheral to the 8085A. It is completely user-pro- 
grammable with 1-kbyte of ROM (8041A) or EPROM 
(8741A) memory for data storage. The UPI allows you 
to fully specify your control algorithm in the peripher- 
al chip without relying on the 8085A. Devices such 
as printer controllers and keyboard scanners can be 
completely self-contained, relying on the 8085A only 
for data transfers. 

The UPI is a powerful 8-bit CPU with a 2.6-ms cycle 
time and an instruction set optimized for bit manipu- 
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4. The 8041A/8741A single-chip microcomputer (UPI-41) 
has its own on-chip ROM and RAM and can be pro- 
grammed to perform various peripheral control functions. 
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5. The UPI’s two data registers are organized so that the 
8085A CPU can write in just one register. and read from 
the other. As a result, the two registers appear as one 
register to the main 8085A CPU. 


lation and I/O operations. It contains an 8-bit 
counter/timer, buffers to communicate with the 
8085A, and two 8-bit programmable I/O ports, which 
can be customized by software or by plugging in 
suitable line drivers or terminators into sockets. The 
UPI also has two input bits that it can test directly. 
An RS-232 driver and receiver on the 80/30 permit 
the UPI to be programmed : as a ample serial- -com- 
munication channel. | | : 


Interfacing | to the on- -board bus 


The UPI interfaces SSyriehnoneusly with the on- 
board bus using two data and two status registers. 
The UPI’s two internal data registers appear: to the 


- 8085A as only one register, since one data register can 


be written into only by the UPI and read only by the 
8085A, and the other can be written into: only by the 
8085A and read by the UPI (Fig. 5). This is-done to 
prevent the two CPUs from siinultaneously writing 
into a data register. 7 

‘The UPI can communicate. with the 8085A by 
loading a data register and then returning to’ its 
previous control task. The 80854. can periodically poll 
the UPI status port for the valid- read (VR) flag, which 
is set in hardware when the UPI writes to its data 
port,-or the UPI can generate an interrupt'to the 8085A 
via an I/O bit that can be programmed to be the VR 
flag. 

Once the 8085A determines the VR flag is true, it 
can transfer the data to its.own memory without 
disturbing the UPI. The VR flag is automatically 
cleared after the data are transferred. Similarly, when 
the 8085A transfers data to the UPI, a valid output 
(VO) flag is set and an interrupt.to the UPI is 
generated (if enabled) automatically. Once the UPI 
transfers the data, the VO flag is cleared. The VO flag 
can also be programmed to:a port bit for generating 
interrupts to the 8085A to indicate that the transfer 
is Vs 


An. extensive interrupt system 


~ The'80/30 provides 12 vectored ovibnity ne 
four of which are handled directly by the 8085A’s 
interrupt-processing capability and routed to fixed, 
unique memory locations. The remaining eight levels 
are handled via the 8259A programmable interrupt 
controller (PIC), which generates a unique memory 
address for each level. These addresses are equally 
spaced at intervals of four or eight (software-selec- 
table) bytes. This 32 or 64-byte block may be located: 
to begin at any 32 or 64-byte boundary in the 65,536- 
byte memory space. A single 8085A jump instruction 
at each of these addresses then provides the linkage 
to locate each interrupt-service routine independently 
anywhere in memory. The PIC provides a selection 
of four priority algorithms so that the manner in 
which real-time requests are processed may be con- 
figured to meet the peanicerneuss of the system pu 
design. | 

The 80/30 also fis two. 8953- based programmable 
16-bit BCD and binary timers/event counters, which 
can be used for a variety of functions. Both timers 
may be set to act as a rate generator (divide-by-N 
counter), @ square-wave generator, a programmable 
retriggerable- one-shot, or’ one of the timers can be 
jumper-selected as an event counter. In addition; an 
interrupt carn be generated when a time interval has 
expired or when a eet number > events ae 
occurred. : 

To. see how useful the 30/30 can be, seeder a 
supervisory control/ monitoring system (Fig: 6) using 
an Intel iSBC 80/30 single-board computer, iSBC.201 


diskette controller, and iSBC 732 analog input/output 
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6. In this application example, the 80/30 forms the heart 
of a remote data-acquisition system. By taking advantage 
of the one-board microcomputer’s dual-port memory and 
universal peripheral interface, the system achieves a 
combination of attractive cost and efficiency. 
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board. Here local commands and process-status sig- 
nals are given and displayed on a CRT, which is 
interfaced via the iSBC 80/30 resident UPI and 
RS232C components. Process variables are converted 
from analog to digital using the analog I/O board. 
Control variables are passed over the Multibus from 
the 80/30 to the 732, where they are converted from 
digital to analog. 

System data are logged on two diskettes, which are 
controlled by the 201. The controller board’s on-board 
DMA interface accesses the 80/30’s dual-port memory 
and stores the data on one of the floppy discs. 

At the end of the day, a remote host processor, 
interfaced to the 80/30 via a modem (through the 
80/30’s 8251A and RC232C circuits) can request all 
or part of the diskette-resident data. Here, the 80/30 
uses its on-board dual-port memory as a data buffer 
for transfers to the host. 

Intel’s RMX/80 real time executive, disc-file system 
and analog drivers provide the majority of the 
system’s software.as 


Note: Multibus and 1SBC are registered trademarks 
of Intel Corp. 
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- Dual-port RAM hikes throughput — 


in input/output controller board 


On-board random-access memory, accessible from system bus, 
makes input/output controller subsystem look like 
just another memory board to the host microprocessor 


by Craig Kinnie and Michael Maerz, intel Corp., Santa Clara, Calif. 


C) Input/output controllers based on microprocessors 
step up throughput in microcomputer systems by reliev- 


Ing the host processor of tedious, time-consuming control | 


tasks—and a new design concept that increases the 
processing capability of this subsystem promises to hike 
throughput even more. It will cut the host intervention 
needed to transfer data and to run the controller. 

In this configuration, all communications between the 
host processor and the controller are handled through a 
section of dual-port memory that resides in the controller 
subsystem. This setup allows more efficient transfer of 
large blocks of data from the 1/0 device to the system 
without contention over access to the system bus. It also 
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simplifies interprocessor communications because the 
subsystem controller appears to the host processor sim- 
ply as an additional RAM board. | , 

Although this concept allows the subsystem to remain 
dedicated to its 1/0 control function and to assume a 
subservient role to the host processor, it has more 
processing power than previous generations of such 
controllers. Hence it has been dubbed the intelligent- 
slave concept by Intel, which applies it in the iSBC 544 
intelligent communications controller. 

The new subsystem architecture is divided into three 
major sections: dedicated 1/0, dedicated computer, and 
dual-port memory (Fig. 1). The dedicated input/output, 


1. Heart of memory. New controller archi- 
tecture includes the dedicated input/output 
circuitry and dedicated processor of an intel- 
ligent peripheral controller, but its heart is 
the dual-port random-access memory. 
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2. Performance advantages. In adding a real-time task to an existing real-time system, the load on the system bus is significantly reduced 
over the traditional multitasking approach (a) or the intelligent controller approach (b) by the intelligent-slave controller approach (c). 
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3. The 544. Based on the 8085A microprocessor with. 4-kilobytes of PROM and 16 kilobytes of RAM, the subsystem is designed as a 
communications controller with four synchronous /asynchronous buffered serial |/O channels, and a 10-bit parallel |/O interface. 
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Dual-port RAM aiso shows up in new single-board computer 


The concept of a dual-port read-write memory used in | the . 


| iSBC-544 communications board is also employed in 
another new Intel product: its latest single-board comput- 


er, the iSBC-80/30. A dual: port makes the 80/30’s: 
random-access memory directly: accessible by the on-. . 


board 8085A central processing unit via internal busing 
without tying up the external system bus, the Multibus. At 
the same time, it also makes the RAM directly accessible 


by any other boards, like direct-memory-access control- 


lers or other one-board computers that may be tied to the 

| Multibus. 
Moreover, the 80/30 adds its dual- -port bus to the 
earlier iSBC computers’ pair of buses: an internal bus, 


which hooks the CPU to peripheral chips and read-only- 


memory program storage and the system bus, over which 
the CPU and other boards communicated with RAM. Eight 
bits wide, the new bus is. connected to a pair of buffer 
registers that coordinate, thus making the RAM accessible 
either by the internal bus or the system bus. 

The objective is throughput: the CPU has priority in 
access to the on-board RAM. But since the access is not 


over the Multibus system bus, which might be tied up, | 


there is no waiting. From the viewpoint of other system 


| boards, the system bus | is Sereeve a greater pelcentage 


of the.time. 


consisting of the necessary peripheral chips, timers, 
buffers, and interface integrated circuits, tailors the 
controller to the application’s I/O requirements. 


' The dedicated computer consists of a general-purpose: 


microprocessor, electrically programmable read-only 
memory, dedicated RAM, timers, interrupt logic, and the 
decode and chip-select logic. The size and speed of the 
central-processing unit can be tailored to match the 
requirements of the dedicated 1/0 section. 

_ The dual-port memory is the heart of the architecture 
and sets it apart from traditional approaches to intelli- 
gent controllers and multiprocessing. Passing all 
commands and data between the system and the control- 
ler’s processor through this memory offers a number of 
significant advantages. 


ates at full speed, since all required memory and 1/o 
resources are immediately accessible on the board, with- 
out indeterminate delays caused by other system activity 
on the bus. This accessibility is especially important in 
real-time systems, since it allows the controller’s 
performance to remain constant even though system bus 
activity may change. © 

Secondly, the architecture presents a consistent and 
convenient interface between the host cpu and all the 
controllers in the system, regardless of function. Because 
the controllers’ dual-port RAM looks to the host CPU like 
just another location in system memory, the hardware 
and software problems associated with connecting multi- 
ple processors together are reduced to interfacing a 
number of identical intelligent memory locations. 

Also, the architecture offers a degree of protection for 
the data in memory. The subsystem computer ‘and soft- 
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With the incorporation of 16 kilobytes of memory on the 
80/30, Intel had little choice but to move to the dual-port, 


triple-bus architecture. The reason is that few system 
_ designs require more than 16 kilobytes, so in many appli- 
cations all’ .boards will be demanding ‘access to the 


80/30’s memory over the Multibus. The CPU had better 
have priority to its RAM, through its own private line, lest 
the queue for the system bus bog down throughput. 

The 80/30 also packs lots of extras, in addition to the 


total 16,384 bytes of read/write memory built with 2116 


16-K dynamic RAMs. A pair of ROM sockets provide 
4,096 bytes of program storage if fitted with 16-K erasable 


programmable read-only memories like the. 2716. When 


pin-compatible 32-K erasable PROMs are available, 
program storage can be extended to 8 kilobytes. 

Also on board is a socket for Intel’s universal peripheral 
interface chip, the 8041 (or 8741 erasable-PROM 
version), which can function as a slave processor to drive 
peripheral devices. An 8251A universal synchro- 
nous/asynchronous receiver/transmitter is included for 
serial communications, and the 80/30 also. boasts three 
16-bit programmable timers. The 24 programmable 


input/output lines are brought out to sockets that accept 
quad line-drivers or -terminators for hc 


ies Capece 


ware can only alter that portion of system memory that. 
resides in its own dual-port memory section. In contrast, 


traditional intelligent controllers have access to the 


entire system RAM and, should a malfunction occur, can 


destroy all of that memory. 


System performance advantages 


Because all processing assigned to the new controller’s 
CPU takes place off the system bus, its architecture offers 
important performance advantages to the system. These. 
advantages come from the appearance of the processed 


data blocks in system memory without consuming any 
_ system resources or bus time 


The advantages of this approach are best demon-. 


- strated by comparing it to alternative means of adding a. 
First, the dedicated computer’s performance can i : 
optimized for its applications. Its software always oper-- 


real-time task to an existing real-time system. In this 
case, the new task requires additional CPU, memory, and 
I/O resources. 

The traditional multiprocessor approach of Fig. 2a 
expands CPU resources in-one of two ways: software 
utilization of reserve capacity in the existing processor, 
or adding another processor. In either case, memory and 
1/0 increments generally will be required. | . 

The primary disadvantages of this approach are the | 
increased complexity of the system software and the 
increased load on the system bus. Both will slow the 
existing real-time system unless it has. been designed 
with adequate reserve. The system bus must also provide 
sufficient capacity for the incremental memory-execu-' 
tion and data-transfer operations. This additional bus 
load will also require that the primary real-time task can 
tolerate CPU delays due to bus contention. - . 

The intelligent-controller approach of Fig. rb has 
gained widespread use since the advent of the micropro- 
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X = ANY PAGE ADDRESS,0 TO F(HEX) 


4. Memory mapping. The variable system memory addresses are 
always mapped into the on-board address of 8000HEX, providing 
software independence for the subsystem and the host. 


cessor. This approach combines the cpu and I/O incre- 
ments onto a single module that usually includes direct- 

memory-access transfer logic. In some cases the execu- 
tion memory for the CPU is included. 

This approach lessens the bus-loading problem since 
the 1/0 data transfers and some memory-execution cycles 
take place off the system bus. However, both CPUs’ 
programs will have to tolerate delays caused by 
increased bus contention. Increased software sophistica- 
tion is the primary disadvantage of this approach, much 
as with the multiprocessing approach of Fig. 2a. 

The intelligent-slave approach of Fig. 2c can be 
viewed as a logical extension to the intelligent-controller 
approach. Combining the cpu, 1/0, and memory incre- 
ments creates a single module that has a minimal impact 
on the existing system software and bus loading. What’s 
more, the subsystem can operate at full capacity without 
regard to other system activity. It can be programmed 
outside the primary system and then added with minimal 
impact on the system software or performance. 

A limitation of the approach is the inability of the 
subsystem to transfer data into portions of the system 
memory space that reside off its board. This problem is 
minimized by the ability of the controller’s RAM to serve 
as a substantial portion of the entire memory space 
addressable by the system. In this light, the on-board 
processor can be viewed as having a DMA capability 
limited to a portion of the system’s address space. 

In a system with more than one of the new controllers, 
the system CPU handles any data that must be trans- 
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TABLE: EIA RS-232-C SIGNALS PROVIDED AND SUPPORTED 


Carrier detect Receive clock 


Clear to send Receive data 
Data set ready Ring indicator 
Data terminal ready Transmit clock 


Request to send Transmit data 


ferred from one to another. Applications involving the 
transfer of large blocks of data would be best served by a 
central block-transfer device elsewhere on the bus. 

The advantages offered by the new approach in this 
example of adding onto an existing system are just as 
applicable to a ground-up design. This modular 
approach to configuring real-time multiprocessing 
systems simplifies hardware and software design, as well 
as system integration. 

While the primary design objective of the new archi- 
tecture is operation in a multiprocessing system, it can 
provide significant utility as stand-alone processors. 
Thus these controllers incorporate a second mode of 
operation called the limited bus-master mode. 

In this mode of operation the new controller can be 
used like a single-board computer as long as it is the 
system’s only master of the bus. It can be connected to 
standard memory or I/O expansion boards to enhance its 
capability. It can even be used to drive other such 
controllers as long as they are used in the subsystem 
mode. This dual operational mode will allow the new 
controllers to serve a broad range of applications. 


Communications first 


Communications applications present complex pro- 
cessing requirements and an inherent real-time nature, 
so it is logical that a communications processor be the 
first of these new controllers to be marketed. The iSBC 
544 intelligent communications controller can serve as a 
flexible front end to an iSBC system or as a cost- 
effective stand-alone processor configured as a terminal 
cluster or line concentrator. Its design (Fig. 3) incorpo- 
rates an 8085A cpu, 16 kilobytes of dual-ported dynamic 
RAM, 4 kilobytes of PROM, programmable interrupt 
control, three interval timers, four programmable baud- 
rate generators, four synchronous/asynchronous buf- 
fered serial 1/0 channels, and a 10-bit parallel interface 
compatible with a Bell 801 automatic calling unit. 

The dual-port memory block basically consists of the 
16-kilobyte bank of random-access memory, which is 
accessible from either the system bus or. the on-board 
processor through the dual-port controller. This memory 
block provides the primary means of communication 
between the system and the on-board 8085A. The port to 
the memory, which looks to the system bus like any other 
RAM card belonging to the system, features full 20-bit 
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addressing and a typical access time of 600 nanoseconds. 

The interface’s address-decode logic’ allows switching 
of the base address of the iSBC 544 to any 4-kilobyte 
boundary in the host system’s address space. In addition, 
the user may reserve 8, 12, or 16 kilobits of the 544’s 
memory for use by the on-board processor only. This 
reserved memory is not accessible from the system bus 
and does not occupy any system address space. The only 
restriction is that all of the unreserved memory reside in 
the same 64-Kk address page of the system memory. 

This memory division can be a significant advantage 
in large 8-bit microcomputer systems. Only that portion 
of the controllers’ memory needed to pass data between 
CPUs must be made accessible to the system. The 
remaining buffer and execution memory does not 
consume any system address space. 

The net result is an increase in the system’s overall 


memory capacity. For example, a microcomputer system. 


that would usually be limited to 64 kilobytes of memory 
has a total memory capacity of over 190 kilobytes when 
driving seven 544s. 


Address maps and interrupts | 


To the on-board processor, the base address of its 
memory is fixed at 8000HEX. Furthermore, all on-board 
addresses are fixed, so that multiple 544s operating on 
the same system bus can be running identical programs 
regardless of their base address on that bus. This capa- 
bility necessitated the address-mapping logic to trans- 
form addresses from the system bus into the equivalent 
in the on-board address space starting at location 
8000HEX (Fig. 4). 

The address-mapping logic also implements the flag- 
interrupt feature. It provides an interrupt to the on- 
board processor whenever a byte is written into the 544’s 
base address from the system bus, and a read from the 
on-board processor to the base address clears the inter- 
rupt. Since each 544 in a system has a different base 
address in that system’s RAM, it also has a unique 
interrupt. This flag-interrupt capability is a key element 
in establishing a protocol for communications between 
the host cpu and the subsystems’ processors. | 

The dual-port control logic is responsible for resolving 
contention over access to the memory and is designed to 
optimize the performance of the subsystem CPU. Unless 


the system bus has initiated a memory cycle before the. 


on-board processor. requests memory, that CPU runs at 
full speed. The maximum delay that can be encountered 
is one memory cycle. The arbitration logic actually 
reserves the memory for the on-board processor before it 
generates the necessary commands. This advance reserv- 
ing guarantees that the on-board cpu will suffer mini- 
mum intervention from system bus accesses. 


When the iSBC 544 is used in the stand- alone limited 


bus-master mode, the dual-port logic is disabled and the 
bus interface buffers are turned around to drive onto the 
bus. This reversal allows. the on-board central-processing 
unit access to the memory of other subsystems or 1/0 
expansion boards on the system bus. 


The dedicated computer is built with an 8085A CPU 


operating at 2.76 megahertz, between 2 and 4 kilobytes 


of PROM and ROMs or 8 kilobytes of ROM using 2332 
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| POINT-TO-POINT 
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TERMINALS 


| LOCAL 
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| MEMORY AND 1/0 


HOST-SYSTEMBUS 


5. Communications applications. Two typical applications of the 
new iSBC 544 would be as a front-end communications processor to 
a microcomputer system and as a remote concentrator to a series of 
point-to-point or multidrop connected terminals. 


mask-programmable parts, 256 bytes of static RAM, two 
16-bit and one 14-bit. interval timers, and a 8259 
programmable interrupt controller for individual receive 
or transmit interrupt inputs for each serial port. — 

Special command-decode logic was added to the CPU 
to. allow it to operate at maximum speed independent of 
other system activity. There are 21 sources of interrupt 
on the 544, including the separate transmit and receive. 
interrupts for each port and separate timer interrupts. In 
addition to receiving an interrupt from the system, the 
544 can also send an interrupt to the system bus via the 
8085A’s serial-output data line. 

Since this controller is intended for communications 
applications, latched interrupts are provided directly to 
the cpu for loss of carrier and ring indicator for all four 
1/0 ports. The ring-indicator and carrier-detect lines car 
also be monitored through the parallel port. 


Dedicated 1/0 | 


The dedicated- V0 section of the 544 aig a high 
degree of flexibility and programmability. This results 
primarily from the inclusion of four 8251A universal 
synchronous/asynchronous receiver/transmitters. These 
devices are programmable for synchronous or asynchro- 
nous mode, character size, parity bits, stop bits, and. 
baud rates. Data, clocks, and control lines are buffered 
with RS-232-C-—compatible drivers and receivers to four. 
26-pin card-edge connectors. Each port is configured as 
a data-terminal interface, but may be converted to a 
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6. From slave to master. In its stand-alone mode, the 544 can operate as a bus master and be configured as an intelligent terminal controller 


connecting dumb terminals to a data link (a) or as a peripheral controller connecting RS-232-C—compatible units to the terminal (b). 


data-set interface by changing a single jumper-plug 
assembly. The ports support most RS-232-C signals 
(those that are listed in the table). 

A programmable baud-rate generator is also provided 
for each port. The range of baud rates available is 75 to 
56 kilobits per second. The generators are implemented 
with 8253 programmable interval timers, which receive a 
jumper-selectable input frequency of 1.84 or 1.23 MHz. 
In addition, one of the CPU’s interval timers can be 
converted to baud-rate operation and jumpered to any 
port to provide it with split-speed operation. 

The 544 also provides a parallel port with four 
RS-232-C buffered input lines and six RS-232-C 
buffered output lines. This port is configured to interface 
to most automatic calling units but may be used as a 
general-purpose I/O port. It is implemented with an 8155 
programmable peripheral interface that also provides the 
256 bytes of static RAM and the 14-bit timer. 


Applications 


A likely common use of the 544 as a subsystem is as a 
front-end processor or terminal multiplexer (Fig. 5) in 
an iSBC system. The 544 performs all communications- 
related functions such as format control, code conver- 
sion, data-link control, error checking, data compression, 
and protocol management. It can handle multiple proto- 
cols, line speeds, and data formats. 

All the system processor sees are the processed data 
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blocks that appear in system memory. An automatic 
dialer could be added to provide a dial-up connection to 
a host processor or network. 

Also shown in Fig. 5 is another 544 used in its limited 
bus-master mode as a remote concentrator and terminal 
controller. The line and memory capacity of the remote 
concentrator can be increased by the addition of stan- 
dard iSBC memory and 1/0 expansion boards. 

The intelligent-terminal controller shown in Fig. 6a is 
a prime example of a 544 used in the stand-alone mode. 
It can connect one or more dumb terminals to a data link 
and provide the necessary buffering, code conversion, 
and data-link control. It could also connect a terminal 
that happens to communicate in a different protocol to a 
new network or to more than one network. 

The iSBC 544’s multiple serial lines do not have to be 
used for cominunications. They can also be used to 
connect RS-232-C-—compatible peripherals to the termi- 
nal (Fig. 6b). In this configuration, the 544 can provide 
message editing and formatting, bulk storage, and hard- 
copy output. 

As this last application suggests, the 544 is the 
vanguard of a family of intelligent 1/o controllers that 
will add tremendous increases in throughput and versa- 
tility to the iSBC line of single-board computers. The 
basic architecture will simplify the task of developing 
multiprocessing hardware and software solutions that 
will overcome throughput limitations. O 
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16-bit euious computer 
maintains 8-bit family ties 


Three-bus 8086-based board addresses a megabyte, 
communicates over expanded system bus 


by Robert Garrow, Jim Johnson, and Les Soltesz, inte! Corp., Santa Clara, Calif. 


C) For the first time ever, 8- and 16-bit single-board 
computers can brainstorm over the same system bus. 
The iSBC 86/12 16-bit SBC has been designed to work 
intimately with its predecessors, the iSBC 80 family of 
8-bit boards. What’s in it for the user? Design flexibili- 
ty —8-bit designs can be enhanced to 16 bits, developed 
software can be transported and, beyond that, 8- and 
16-bit devices can be mixed in multiprocessing configu- 
rations. Several features make these options possible: a 
16-bit CPU and instruction set designed for 8-bit compat- 
ibility; greatly expanded memory resources; and an 
extension of the Multibus specifications. 

At the heart of the iSBC 86/12 is a 16-bit, high- 
performance metal-oxide-semiconductor 8086 central 
processing unit that operates at 5 megahertz. Because 
the 8086 instruction set is a superset to that of both the 
8080A and 8085A 8-bit processors, the CPU can execute 

the full set of 8080A/8085A-type 8-bit instructions plus 


PROGRAMMABLE 
INTERRUPT CHIP 


PERIPHERAL 
INTERFACE 


DUAL-PORT RAM 
CONTROLLER 


MULTIBUS/MULTIMASTER 


1. What a board. The iSBC 86/12 has 32 kilobytes of RAM and room for 16 kilobytes of ROM. The 5-MHz 8086 CPU executes 
8080A/8085A-type as well as 16-bit instructions, including multiply and divide. Address space has been increased to a megabyte. 
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a new set of 16-bit instructions. Thus, programs gener- 
ated for 8-bit-cPU systems can easily be upgraded to run 
on the iSBC 86/12 using the software tools available 
with the Intellec microcomputer development system. 
Programs written in Intel’s high-level programming 
language, PL/M, can be executed. on both iSBC 80 and. 
iSBC 86 products, preserving the software investment in 
8-bit systems as a user moves into 16-bit applications. 

Other features of the 8086 CPU are signed 8- and 
16-bit arithmetic (including multiply and divide), effi- 
cient interruptible byte-string operations, and improved 
bit manipulation. Furthermore, the 8086 provides mech- 
anisms for reentrant code, position-independent code, 
and dynamically relocatable programs. 

This enhanced processing power is supported by the 
largest memory ever offered on a cpU board (Fig. 1). 
Memory address space has been extended over the iSBC 
80 series to one million bytes. Up to 16 kilobytes of 
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2. LSI+ SBC =86/12. A number of programmable LSI devices take credit for the power and flexibility of the iSBC._ 86/12. Note their 
interconnection to the three-bus hierarchy. When the 8086 requests a resource, the system bus is used only as a last resort. 


read-only memory can be installed on the iSBC 86/12 
itself. Furthermore, an additional 32 kilobytes of 
dynamic random-access memory with on-board refresh 
may be accessed independently by the cpu or by the 
system bus (Multibus). _ 

Like the iSBC 80/30, the 86/12’s RAM has dual ports 
to extend its use off board for access by other Multibus 
masters, including single-board computers, direct-memo- 
ry-access devices, and peripheral controllers [Electronics, 
Aug. 17, p. 109]. All memory operations on the board 
occur independently of the Multibus, freeing it for exter- 
nal parallel operations. For applications that require 


data integrity at all times, a separate bus supplies power 


to the RAM and support logic via the edge connector. An 
auxiliary power source energizes the RAM in the event of 
power failure. 


Multibus— the new look 


To exploit the. greater performance of the 8086 cpu 
and simultaneously make the iSBC 86/12 fully compati- 
ble with the iSBC 80 family of sBCs and expansion 
products, the Multibus specification. has been extended 
to support 20 bits of address and 16 bits of data. The 
control lines, too, have been expanded to direct 8- and 
16-bit data transfer over the system bus. These improve- 
ments enable the iSBC 86/12 to address directly a full 
one megabyte of system memory, access data in 8- or 
16-bit word lengths, and recognize and acknowledge a 
variety of interrupts. 

Address space has been enlarged to 1 megabyte. by 
adding four address lines, Aio~A13. Next, 8- and 16-bit 
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data operations have been defined to permit both types 
inthe same system. This is done by reorganizing the 


memory modules, adding one new signal and redefining 
another. The memory-is divided into two 8-bit data 
banks, which form a single 16-bit word. The banks are 
organized such that all even-byte-addressed data is in 
one bank (Do-D;) and all odd-byte—addressed data. is in 
the other bank (D;-Dr). A new bus-address signal has 
been defined to control the odd-byte bank called byte 
high enable (BHEN) during 16-bit operations. When 
active, BHEN enables the high byte of the data word from 
the addressed boards on the Ds-D; Multibus data lines. 
Ao controls the even byte bank and, when inactive, 
enables the low byte of the data word on the Do-D; 
Multibus data lines. All word operations must occur on 
an even-byte-address boundary with BHEN active for 
maximum efficiency. (Ao is inactive for all even 
addresses —see the table.) Word operations on odd-byte 
boundaries will be converted to 2-byte operations by the 
8086, one for low-byte, one for high-byte. Byte opera- 
tions can occur in one of two ways. The even bank is 
accessed when BHEN and A, are both low. This puts the 
data on Do-D7. To access the odd bank (normally placed 
on D;-Dr during a word operation), a new data, path has 
been defined. The active state of Ao and the inactive 
state of BHEN are used to enable a swap-byte buffer, 
which places the odd data bank on Do-D;. This permits 
an 8-bit master access to both bytes of the data word 
while controlling only Ao. Ao therefore specifies a unique 
byte and is not part of the word address, since all word 
operations are on even-byte boundaries. | 
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The iSBC 86/12 owes much of its flexibility to program- 
mable large-scale integrated devices. An 8255A peripher- 
al interface chip provides 24 programmable I/O lines that 
may be tailored to the customer's needs by simply 
- programming the device for input, output, or bidirectional 
modes with or without handshaking abilities. In conjunc- 
‘tion with the 8255A’s configuration the user may then 
‘select appropriate line drivers and terminators for the |/O 
lines that can be inserted into sockets on the iSBC 86/12 
board. 
An 8251A universal synchronous/asynchronous receiv- 
er/transmitter is included to provide an RS-232-C inter- 


face..for serial communication with. other computers, RS- 
232-C-type peripherals (cassette tape, modems, etc.) or 
cathode-ray-tube terminals. The 8251A enables the user 
- to customize the communication link. Synchronous /asyn- 
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chronous mode, data format, contro! character format, 
parity and baud rates from 75 to 38.4 kilobauds are all 
under program control. | 

For system timing functions an 8253 programmable 
interval timer provides two programmable timers, each of 
which may be used as a square-wave generator, retrigger- 
able one-shot multivibrator or as an event counter. | 

The interrupt structure of the iSBC 86/12 encompasses 


handled by an 8259A programmable interrupt controller 


One nonmaskable interrupt is available to immediately 
alert the CPU to catastrophes like a power failure, in which 
case the CPU can branch to an appropriate routine in 
memory to effect an orderly system shut-down. . 


SYSTEM 
_ MEMORY. 


3. RAM, please. The 8086's view of on-board memory is fixed from zero to O7FFFH. When an outside master accesses this space, the DP | 
controller performs the translation. Here, locations O6000H to O7FFFH are available to another master by addressing CAOOOH to CBFFFH. | 


Since all 8-bit accesses via Multibus are done on the 
lower byte of the data word, the iSBC 86/12 can access 
8-bit memory or 1/0 devices from the system bus. This 
makes the iSBC 86/12 compatible with all iSBC 80 
Multibus modules. © | pe 


More interrupts, too 


‘The iSBC 86/12 expands the previous Multibus defi- 
nition of interrupts by creating two distinct types: non- 
bus-vectored (NBVI) and bus-vectored (BVI) interrupts. 
Each Multibus interrupt line can be individually defined 
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through software to be a BVI or NvBI. Using BVIs, the 
interrupt capability of a Multibus system can be — 
increased to 64 bus-vectored-priority interrupts. 

Using NBVIs, a slave module activates an interrupt line 
and the interrupted bus master generates its own restart 
address to service that interrupt. The Multibus address 
or data lines are not used. A.BvI uses the Multibus 
address and data lines to communicate with the inter- 
rupting slave. When the slave module generates an inter- 
rupt, the bus master requires that module to generate the 
restart address. One additional command signal is 
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4. Open loop. Shown above is a simple alarm and monitoring system. The iSBC 711 analog-input board samples 16 differential inputs and the 
8-bit iSBC 80720 compares the inputs to the high and low limits. An alarm condition illuminates an LED and gets logged-on a teletypewriter. 
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5. Closed loop. Suppose the system in Fig. 4 needs to be upgraded to handle a closed-loop system. For this application an iSBC 86/12 
replaces the 80/20-04 to cope with the higher processing. The output control variables are handled by an iSBC 724 analog-output board. 
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6. Multi/master. To enhance the control system in Fig. 5, add a dedicated CPU to control valves, vents, and dampers that, in turn, affect 
pressure and flow parameters in the system. This has been done by adding an iSBC 80/05 in a Multibus / multimaster arrangement. | 


defined—interrupt acknowledge (INTA)—to request the 
restart address from the slave module. 

The iSBC 86/12 board architecture, like that of the 
8-bit iSBC 80/30, is organized around a three-bus hier- 
archy: an on-board bus, a dual-port bus and a system bus 
(Multibus). All three buses have been expanded over 


their 80/30 counterparts to incorporate 20 address lines 


and 16 data lines. 
The iSBC 86/12 architecture 


The on-board bus links the 8086, all the 1vo peripher- 
als, and the read-only memory. Next in the hierarchy is 
the dual-port bus, which connects to the DP controller, 32 
kilobytes of dynamic RAM, and the dynamic RAM 
controller. Finally, the system bus permits expansion of 
system resources through Multibus modules (Fig. 2). 


The bus protocol of the iSBC 86/12 dictates that each: 
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of the three buses communicate with an adjacent bus or 
operate independently. When the CPU makes a request 
for a resource, the on-board and dual-port buses simulta- 
neously determine if their hardware can fulfill the 
request. If the on-board bus is able to acknowledge the 
request, it does so and the Dp bus is not disturbed. (The 
DP bus is not interrupted to determine whether it can 
acknowledge the request.) The 8086 always controls the 
on-board bus, and requested operations can be 
completed without delay. If the pp bus is needed, it is 
requested and the dual-port controller grants the use of 
the bus to the processor. Thereafter, the dynamic-RAM 
controller completes the operation and generates an 
acknowledge. 

If neither the on-board nor the Dp bus can satisfy the 
request, the CPU asks for the system bus. The 8086 must 
use the on-board and dual-port buses to communicate 
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7. Four loops. An iSBC 86/12 can be used in conjunction with an iSBC 544 intelligent communications controller to peiform a supervisory: 
function for four closed-loop systems. The iSBC 544 controls the line protocol and the iSBC 86/ 12 processes the 544’s data. - 


with the system bus. The 8086 takes control of the Dp 

bus when the system bus is granted. This prevents lock- 

out problems with the pp bus—that is, when the proces-_ 
sor requests the system bus while another bus master has 

control of it and is accessing the dual-port RAM. : 

Naturally, the fewer the buses it has to access, the 
faster the iSBC 86/12.completes a transaction. The 
on-board bus always operates at maximum board speed. 
But the pp bus operates at maximum board speed only if 
it was not busy or taken up with a memory refresh cycle. 
When the system bus is brought into play, the processor 
speed depends on the overhead in acquiring it and the 
type of Multibus module being accessed. 

With this three-bus architecture the iSBC 86/ 12 can 
be operating over its:on-board bus at the same time as 
another Multibus master is using the system bus. It does 
so by accessing data from the DP RAM at no reduction in 
board speed. The on-board bus permits access only from 
the 8086. Thus all 1/0 and ROM are private to the 8086. » 

The dual-port controller has two independent address 
decoders —one for the 8086 and one for the Multibus. 
The 8086 decoder fixes the 8086’s RAM addresses from 


hexidecimal 00000 to O7FFF using a fusible-link | 


programmable ROM. The Multibus decoder allows the 
user to select any address range for the on-board RAM by 
specifying two parameters—a -top-of-memory pointer 
and the size of the accessible memory. The TOM pointer 
(as seen by another Multibus master) can be set to any. 
8-kilobyte boundary in the 1-megabyte memory space. 
The amount.of memory on the iSBC 86/12 accessible by. 
another master can be set to 8, 16, 24, or 32 kilobytes (or 
no access) with an on-board jumper. For example, fixing 
the accessible memory size to 24 kilobytes provides the 
8086 with 8 kilobytes of RAM that only.it can access. 
This private area can be used for the processor’s stack, 
interrupt jump table and other special system paramet- 
ers that are generally protected from other Multibus 
masters. The only addressing restriction is that the 
memory block accessible to the: miuiius cannot cross a 
128-kilobyte boundary. _ : 
Suppose a Multibus. master wants to load a program. 
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into the iSBC 86/12’s dual-port RAM for execution. 
Since the 8086’s view of the DP-RAM address space is 


fixed, the Multibus address must be translated into the 


on-board 8086 memory space. The DP controller. 
performs this translation. by mapping the TOM pointer’ 


(as seen by other Multibus masters) to 8086-address. 


O7FFFH, the. top of the 8086's on- -board RAM. Point- 
er—1 is mapped to the top of 8086 on- -board RAM— 1, 


_and so on. 


In the example shown in Fig. 3, the Multibus address 
selection is divided into three parts—two selecting the’ 
TOM pointer (X and Y) and one selecting the size of the. 
accessible memory (Z). The TOM pointer is equal to a 
1 28- kilobyte segment (X) plus address displacement (Y): 
from that segment. In this example, X is.set to COO00H 
and Y is set to OBFFFH, so the Tom pointer equals. 
CBFFFH. Next, the size of the accessible memory (Z) is. 
set, in this case to 8 kilobytes. This address translation 
makes the top 8 kilobytes of the 8086’s RAM locations: 
06000H to 07FFFH available to another Multibus: 


master when it addresses locations CAO00H to © 


CBFFFH. The 8086 still has 24 mene epee to 
OSFFFH) of private memory. ae 


Miltiprecessing schemes 


In multiprocessing systems, a master ‘must be able to 
access the system without another master obtaining the 
bus. The iSBC 86/12 incorporates. bus-arbitration logic. 
to effect these transactions. Since the system bus is only 
requested when a system resource is. needed, the iSBC 
86/12 can perform true parallel processing with other 
iSBC 80 or 86 masters. 

A typical example is the use of a common memory 
location that contains the status’ byte (busy/not busy) of 
a floppy-disk controller. When the floppy disk is needed, 
the master must first read the location and, if not busy, 
write the status word without. another master. obtaining 
the bus (to use the floppy disk). A bus-lock function on 
the iSBC 86, once enabled, allows the iSBC 86 to 
maintain control. of the system bus until the lock is 
disabled by program control. This bus- lock function may 
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be activated in one of two ways—by an output bit from 
the resident 8255A peripheral-interface chip or by a 
software prefix on any 8086 instruction. The iSBC 86 
can perform the test and set function by exchanging the 
accumulator with the memory location, preceding the 
instruction by a lock prefix. For example, the status 
word is read into the accumulator and, without another 
intervening bus cycle, a busy status is written. The 
accumulator is then tested: if busy—try again (writing a 
busy does not destroy status as it was already busy); if 
not busy, the floppy disk is now under the master’s 
control and the status location is set to busy. 


The iSBC 86/12: a design tool 


For system debugging and full-speed execution, the 
iSBC 86/12 can be linked to the Intellec microcomputer 
development system. Programs generated on the Intellec 
system can be downloaded into the iSBC 86/12 RAM via 
cables. Through a virtual-terminal capability, the Intel- 
lec console can directly access an iSBC-resident monitor, 
which provides commands for software debug. Once the 
debugging cycle is completed, the user has the option of 
uploading the software back to the Intellec for storage 
on diskettes. 

The Multibus and form-factor compatibility of the 
8-bit iSBC 80 and 16-bit iSBC 86 single-board comput- 
ers provide a degree of design flexibility previously unob- 
tainable. Initial design problems can be solved with 
low-cost 8-bit hardware. As product requirements 
evolve, 16-bit performance can be added. Eventually, 8- 
and 16-bit multiprocessor solutions can be conveniently 
implemented. 

Consider the application shown in Fig. 4, an alarm 
and monitoring system in a typical process plant. Sixteen 
differential inputs from pressure and flow transducers 
are sampled once every second, then compared to high 
and low limits previously entered through thumbwheel 
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SWAP-BYTE BUFFER 


ODO-BYTE BUFFER 


switches. The iSBC 711 analog-input board takes care of 
sampling the inputs and the 8-bit iSBC 80/20-4 com- 
pares the data to the high and low limits. Whenever 
these limits are exceeded, an alarm LED lights up and the 
alarm condition is logged on the system teletypewriter 
along with input identification, high limit, low limit and 
sampled value. 


Closed loops 


Instead of an open-loop system, suppose the design 
must be enhanced to control four output variables — 
thereby making it a closed-loop system. The sampling 
rate must be increased to once every third of a second 
and more processing will be required to run through the 
control algorithm and output the control-loop data. For 
this application, and 1SBC 86/12 replaces the 80/20-4 to 
handle the higher processing requirements. An iSBC 724 
analog-output board is also added to provide the four 
output-control variables (see Fig. 5). Carrying this 
example one step further, one may want to dedicate 
another processor to controlling valves, vents, and damp- 
ers that in turn affect pressure and flow parameters in 
the system. This can be done by adding an iSBC 80/05 
in a multimaster arrangement as shown in Fig. 6. 

Finally, an iSBC 86/12 can be used with an iSBC 544 
intelligent communication-controller to supervise four 
closed-loop systems of the type shown in Fig. 6. The 
86/12 of each system interfaces with the supervisory 
system via its serial interfaces, which are connected to 
the iSBC 544’s serial ports (see Fig. 7). The iSBC 544 
performs the control functions associated with the line 
protocol. The supervisory iSBC 86/12 can access the 
iSBC 544’s dual-port memory and can perform further 
processing of the data received from the four closed-loop 
systems. In this configuration large amounts of memory 
may be required; since the iSBC 86/12 can address up to 
1 megabyte, this presents no problem. ‘a 
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FEATURE 


A new family of MULTIMODU LE™ boards 
extends the solutions provided by 
Intel’s single board computers 


ae 
st 
whe 


Figure 1. The iSBX 350™ Programmable I/O MULTIMODULE plug-in, 
shown here, connects directly on one end into the special iSBX 
bus connector and screws onto the edge of the single board com- 
puter on the other end. 
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‘complete new family of products, called 
MULTIMODULE boards, has been announced 
by Intel Corporation. The new MULTI- 
MODULE boards designed to extend the func- 


\ tional capabilities. of single board computers at much 
Tower cost than has been previously possible. Intel is 
-. supporting the MULTIMODULE concept with a new 


bus’ standard—the iSBX bus. The iSBX bus will now he 


designed into a new generation of single board com- 


puters to: achieve compatibliity withthe emerging iSBX 


bus compatible MULTIMODULE product line. Users of 


Intel's single board computers can incrementally 
expand system resources by adding small (2.85” x 3.7”) 
iSBX: MULTIMODULE boards which Des directly into 
iSBC boards... 


Three new. iSBX bus MULTIMODULE she ins shave 


been introduced—modules for parallel 1/O, serial I/O, 


AFN-01931A 


Re LULLLLLL | ae 


a 
> G 
rv 
« 
o- 
J 


3 a 1003067-" 


Figure 2. The iSBX 350™ Programmable !/O MULTIMODULE™ - 
board provides 24 programmable I/O lines using the 8255A-5 pro- 
grammable peripheral interface. Sockets are provided for inter- 
changeable line drivers/ terminators. 
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Figure 3. The iSBX 351'™ Serial I/O MULTIMODULE board extends 
the serial communications capability of a single board computer 

via an Intel® 8251A USART. It includes an on-board programmable 
baud rate generator, two programmable 16-bit BCD/binary timers, 
and RS232C or RS422/449 interfacing. 
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Figure 4. The iSBX 332™ Floating Point Math MULTIMODULE 
board uses an Intel® 8232 Floating Point Processor and is com- 
patible with the new proposed IEEE format. It provides users with 
both single-precision (32- bit) and double. “precision (64- bit) 
arithmetic functions. — 
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and floating-point math. The showcase for the MULTI- 


_- MODULE family is the iSBC 80/10B board—the first 
~» iSBX bus compatible single board computer. 


-MULTIMODULE™ boards allow users to 
tailor board level products 


oe can choose MULTIMODULE boards to 


| mhecisely configure single board computers for their in- 


dividual applications at'a lower cost. The MULTIMOD- 

ULE boards enable users to buy exactly the capabilities 
that they require for their isBC-based systems. This 
can, of course, Keep. system size and system cost at a 
minimum. 

Any of the three new iSBX bus MULTIMODULE 
products—the iSBX 350 Programmable I/O, the iSBX 
351 Serial I/O, and the iSBX 332 Floating Point Math 
board—plug into a special interface called the iSBX bus 
on the iSBC 80/10B single board computer, (see Figure 
1}. The iSBX bus is being introduced by Intel to facilitate 
the interface betweeen the iSsBX MULTIMODULE 
boards and the iSBC products. The iSBX bus will 
become a standard, similar to the standard MULTIBUS 
system architecture. The new iSBX bus allows system 
expansion through the new MULTIMODULE boards 
without making any demands on the system's MULTI- 
BUS interface. As a result, the system design achieves 
maximum on-board performance while freeing up the 
MULTIBUS interface for other system activities. 


iSBC 80/10B™ board is customer-expandable 


The new iSBC 80/10B single board computer is fully 
compatible with the popular iSBC 80/10A, but it is 
customer-expandable in ‘‘all directions'’ This board can 
be expanded in three dimensions to tailor EPROM, 
RAM, and I/O needs directly on the board. This gives a 
user a built-in adaptablility on one board that was 
previously unattainable. First, the user can choose four 
types of Intel PROMs—the 2708, 2758, 2716 or 2732— 
expandable up to 16K bytes. Second, 1K of RAM 
memory is included on-board and may now be extended 
up to 4K with the use of standard Intel 2114A-5 1K x 4 
static RAMs. Sockets on the 80/10B board are provided 
for these additional RAMs. Input/output is the third 
dimension in every single board computer and may now 
be expanded on-board the iSBC 80/10B by using one of 
the iSBX bus MULTIMODULE boards. In addition, a 
1.04 millisecond timer has been added as.a standard 
feature of the iSBC 80/10B board. In comparison, the 
iSBC 80/10A board has only 1K of on-board RAM, 8K of 
EPROM memory, no I/O or memory expansion 
facilities and no timer. 

Two of the new MULTIMODULE boards—the iSBX 
350 and iSBX 351—provide expansion to the I/O 
already on the iSBC 80/10B board. The iSBX 350 Pro- 
grammable I/O MULTIMODULE (see Figure 2) pro- 
vides 24 I/O lines with sockets for interchangeable line 


AFN-01931A 


~ 
*;, 


ee aen 
Pewee es 


ee, 
PROP Po nae 


iSBC 80/10B ™ Single Board Computer 


_ Here’s what iSBX™ bus MULTIMODULES™ 
provide the user: 
«The ability to incrementally expand the iSBC Single 


‘Board Computer, via iSBX bus, allowing the user to 
add only the function his application requires. 


¢ The on-board addition of totally new capabilities 
(mathematics processing and the like) to single 
board computers. 


-¢ Maximum performance by reducing traffic required 
for standard expansion boards on the industry stan- 
dard MULTIBUS interface. 


* Compatibility with future 8-bit and 16-bit single 
board computers from Intel 


¢ Ahigh-reliability, 36-pin iSBX 960-5 male connector 
for customer design 


drivers and terminators. The iSBX 351 Serial I/O 
MULTIMODULE (see Figure 3) provides program- 
mable, synchronous/asynchronous RS232C or 
RS422./449 compatible serial expansion with fully soft- 
ware selectable baud rate generation. Additionally, two 
programmable 16-bit BCD and binary timers are 
available, allowing iSBC 80/10B users to implement 
programmable timing functions directly on the board. 
A third MULTIMODULE board which users may 
select, provides additional on-board mathematics 
capability to their single board computer. The iSBX 332 
Floating Point Math MULTIMODULE board (see Figure 


New iSBX 960-5™ MULTIMODULE™ connectors 
are available off- ‘the- shelf 


4) is compatible with the proposed IEEE format stan- 
dard. It offers single-precision (32-bit) and double- 
precision (64-bit) arithmetic functions including Add, 
Subtract, Multiply and Divide. It also includes end- of- 
operation and error interrupts to its host iSBC single 
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board computer and full software reset control. 

User may easily implement their more specialized 
requirements on the new iSBX bus through a readily 
available 36-pin male connector, the iSBX 960-5 
(packaged with 5 connectors). In addition, Intel is pro- 
viding an iSBX bus specification describing the elec- 


trical and mechanical. parameters of the interface. The. 


iSBX 960-5 male connectors.mate directly to the female 
iSBX bus connector on the iSBC 80/10B single board - 
computer. The connector, together with the iSBX bus 
specification, allows system designers to take full ad- 
vantage of MULTIMODULE benefits. 

New MULTIMODULES boards will be introduced— 
as will new generation iSBX bus compatible iSBC single 
board computers—by Intel throughout the remainder of 
1980 and into the future. MULTIMODULE boards and 
the iSBX bus represent a maior commitment by Intel for 
the future and offer system. designers new options to 
complement single board computers and MULTIBUS 
expansion. 

The immediately available MULTIMODULE 
family—with the iSBC 80/10B single board computer— 
provides great flexibility and savings for users. The op- 
tions now exist to expand a system in small increments 
with MULTIMODULE boards, or in large increments 
with MULTIBUS boards. And, with the three dimen- 
sional expansion capability of the iSBC 80/10B board, 
the user may configuré his entire system on-board to 
achieve a. single Pas low cost solution. | 


“Call. your. iGeal Titel sales Mike or distibacee for 
the latest: prices on all of the MULTIMODULE 
products” - 


AVAILABILITY: Now” 


LITERATURE: “G8BC 80/ 108 Single B Beard ne 
7 Data Sheet 


_iSBX 350 MULTIMODULE Data Sheet N/C 
-iSBX 351 MULTIMODULE Data Sheet N/C 
iSBX 332 MULTIMODULE Data Sheet N/C 


PRICE: 


N/C 
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Special-function modules 
ride on computer board 


smaller cards donate floating-point processing or added serial and parallel !1/O 
to primary single-board computer; memory is extensible on the main card 


by Gary Sawyer, Jim Johnson, David Jurasek, and Steve Kassel, intel Corp., Hillsboro, Ore. 


(1 In the design of board-level computers, two basic 
methods coexist. One is to pack each card with inte- 
grated circuits to the limits of its capacity, and the other 
‘is to distribute the computer functions among other 
‘boards occupying additional card slots. 

Both approaches have their advantages. The single 
powerful module conserves space and expensive connec- 
tors, while the decentralized boards allow the user to 
pick and choose functions—and add them incremental- 
ly—although the expense of one board might spell over- 
kill for one particular application. 

A new concept in single-board computer architecture 
strikes a neat compromise between both camps. Rather 
than cram more chips on an already overstuffed board, 
the idea is simply to provide it with a connector for 
plugging in smaller modules having limited functions for 
‘specialized applications. 


Best of both worlds 


This is the idea behind iSBX Multimodule boards, 
which cost from $155 to $450 apiece. Plugging into a 
primary processor card,:-10.5-square-inch boards with 
various types of memory or input and output functions 
provide the larger single-board.computer with more ver- 
satility. Linking’ the base board and these Multimodule 
boards is a new 36-line bus called the iSBX bus, for 
‘Single-board expansion. . This interface is destined to 
match the popularity of the main poand: S Pees inter- 
face connector (Fig. 1). } 

The iSBX. bus is derived. direday rer the on-board 
microprocessor system bus and, as such; :an. iSBX- 
compatible board becomes an integral | element of the 
‘single- board computer. The physical interface uses a 


unique connector designed specifically for the iSBX bus... 


The bus is brought to a: female connector on the single- 


_board computer; its male ee is resident < on | the: 


iSBX board (Fig. 2). 

~The iSBC 80/10B board in Figs. 1 and 2 is alie first 
-single-board computer to be compatible with the iSBX 
bus. Upwardly compatible with its predecessor, the iSBC 


80/10A, the iSBC 80/10B is functionally equivalent but. 


Offers significant enhancements. 

The iSBC 80/10B board offers direct functional 
expansion in three dimensions— not only read-only mem- 
ory (as in the iSBC 80/10A), but also static random- 
-access memory and input and output, as facilitated by 
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the Multimodule boards. One kilobyte of static RAM is 
provided along with sockets for expansion in increments 
of 1-K bytes to 4-K bytes using standard 2114A-5 memo- 
ries. Read-only memory may be expanded with standard 
ultraviolet-light-erasable and mask-programmable types 
to 16-K bytes. 

The iSBC 80/10B also features an on-board 
1.04-millisecond timer with ongoing clocking that users 
may optionally configure for microprocessor interrupts. 
In addition, power-fail control is provided for the 2114A- 
5 static RAMS, enabling the user to add battery backup if 
the memory contents must be preserved. 


Three Multimodule boards 


Being introduced along with the iSBC 80/10B are 
three Multimodule boards that expand the functional 
capacity of the single-board computer. Two of these, the 
$155 iSBX 350 and $230 iSBX 351, provide the same 
kind of input/output functions as are to be found on the 
processor board, only more of them. 

For example, the 48 programmable 1/0 lines on the 
iSBC 80/10B board may be expanded to 72 lines by 
simply plugging in the iSBX 350 module—a 50% 
increase. Serial 1/O is similarly expanded with the iSBX 
351 module, which provides a programmable universal 
synchronous-asynchronous receiver/transmitter, or 
Usart (an 8251A), for compatibility with the RS-232-C 
and RS-449/422 interfaces. The iSBX 351 module fur- 
ther offers software-selectable baud rates and two pro- 
grammable 16-bit binary or binary-coded decimal 
timers. 

The third Multimodule board adds otherwise unavail- 
able high-speed math capabilities to the iSBC 80/10B 
board. The $450 iSBX 332 board uses the 8232 floating- 
point processor for arithmetic compatible with the stan- 
dard currently being proposed by the Institute of Electri- 
cal and Electronics Engineers. 

Many applications require a custom design. To com- 
plement the standard family of Multimodule boards, the 


_iSBX 960-5: is provided. This includes five male iSBX 
connectors, and a full bus specification is available for 


custom interfacing by the user. This combination per- 
mits a user to satisfy his or her requirements for special- 
ized 1/0 interfaces with the Multimodule concept. 

The Multimodule concept can be divided into two 
logical elements: base boards and Multimodule boards. 
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1. Distributed. The first processor card to receive the iSBX bus connector is the iSBC 80/ 10B, a follow-on to the iSBC 80/10A. The off-board 


system bus Is the Multibus, which interfaces to the on-board system bus. This, in turn, connects to the Multimodule board connector. 


The base board is the master of the system in that it 
controls communication between the base’s microproces- 
sor and the Multimodule board’s port. Though the first 
base board is a. single-board computer the iSBC 
80/10B Multibus-compatible slaves and intelligent 170 
boards will also incorporate ISBX bus interfaces. The 
Multimodule board is a slave of the system in that it 
carries out 1/0 commands from the base board, 


The iSBX interface 


The iSBX bus specification includes both electrical 
and mechanical characteristics. The mechanical inter- 
face is convenient and rugged; the Multimodule board ts 
mounted to the base board in two places, at the top with 
a screw and at.the bottom by the iSBX bus connector. 
The connector is extremely reliable. It has gold-plated 
phosphor-bronze contacts, it is keyed to assure proper 
orientation, and a shroud protects its pins during han- 
dling. The connector also incorporates interlocking tabs 
to ensure a solid mechanical interface. 

Electrically, the iSBX ‘bus interface lines can be 
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grouped into six. classes. control, address and chip 
select, data, interrupts, options, and power—for a total 
of 36 signal lines. 

Control lines can be further grouped into those for 
commands, initialization, a clock, and system control. 
The two command lines (lORD/- and IOWRT/) are 
active-low I/O-read and -write signals that control the 
communication link between the base board and the 
Multimodule board. With a chip-select signal, an active 
command line indicates that the address lines are valid 
and that the Multimodule board should perform a speci- 
fied operation. 

The initialize line (reset) 1s an active-high input line 
from the base board that puts the Multimodule board 
into a known internal state. The clock line (MCLK) has a 
frequency of 10 megahertz, +0% or -10%. Being asyn- 
chronous with respect to all other Multimodule signals, 
this frequency can vary frony base board to base. board. 

The remaining control lines, MWAIT/ and MPST, are 
output signals from the Multimodule board that control 
the state of the system. MWAIT/, active low, puts the 
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2. Three to one. Below is the iSBC 80/10B main processor board, and above it are the three new Multimodule boards. They are, from left to 
right, the iSBX 351 serial |/O module, the LSBX 350 parallel |/O module, and the iSBX 332 floating-point mathematics Multimodule board. 


base-board processor into a wait. state, allowing the. 
Multimodule board extra’ time to pert form a requested © 
operation, if necessary. MWAIT/ is .generated from 
address and chip-select information only. MPST is. tied to 
ground on the Multimodule board to inform the base 
board that a Multimodule board has been installed. 

The second class of iSBX bus lines includes the 
address lines (MAo-~MA,2) and the chip-select lines 
(MCSo, and MCS,,). The base board decodes 1/0 
addresses to generate the chip-select signals for the 


Multimodule boards. In so doing, it normally decodes all 


but the three lowest-order addresses: (MAo-MA,). 
base board normally reserves two blocks of eight 1/0 
ports for each iSBX bus connector provided. 


Defining the lines 


Eight bidirectional data. lines (MDo- MD;, active 
high) carry information to and from the Multimodule 
ports. MDo is. the least significant bit. The two active 
high interrupt lines from the Multimodule board, 
MINTRo. and MINTRi, make interrupt requests to the 
base board. 

Two optional lines, OPT» and OPT, are connected to 
wire-wrapped posts on both the base and Multimodule 
boards. They may serve either as additional interrupts 
from the Multimodule board or as special signals from 
the base board. a , 
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Finally, all base.boards provide +5 and £12 volts to 
the Multimodule boards. These power lines complete the 
six ISBX bus classes. 

The primary function of the iSBX bus j is to provide a 
path for 1/O-mapped data between base board and Mul- 
timodule board. This happens when the base board per- 
forms an I/O-read or I/O-write operation. There are two 
types of 1/O-write operations, and the Multimodule 
board determines which is perlonnes 


Data transfers 


The first is a full- eeedsi 1/0 write (Fig. 3), The. base 
board generates a valid 1/O address and chip-select and 
activates the IOWRT/ line after the set-up times are met. 
The IOWRT/ line will remain active for a minimum of 
300 nanoseconds and the data will be valid for a mini- 
mum of: 250 ns before 1OWRT/ is removed. The base 
board then removes the data, address, and chip-select 
signals after the hold:times shown in the timing diagram. 

.The alternative I/O write. is a_ write-with-wait, 
used by Multimodule boards that cannot write into an 
1/0 port at full speed. Again, the base board generates. a 
valid address and chip-select. The Multimodule .board 
activates the MWAIT/ signal based on address and chip- 
select information. This will remove. the ready condition 
from the processor, causing it to go-into a wait state after 
the write command has been activated and valid data 
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ADDRESS 
(MA j-MA>) 


CHIP SELECT 
(MCS; ) 


_ VALID ADDRESS | 


WAIT 


I/O WRITE 
(LOWRT) 


DATA BUS 
(MD9—-MD,) 


FULL-SPEED 


VALID ADDRESS 


WITH WAIT STATE 


3. Write types. Two modes of sending information to a Multimodule board are available: full-speed and with a wait state. The wait line is not 
used for peripherals that meet the full-speed specifications. The wait signal extends the time for which data remains valid. . 


provided. The Multimodule board will remove the 
MWAIT/ signal —allowing the processor to leave its wait 
state—when it has satisfied the write-pulse—width 
requirement. The base board removes the write com- 
mand, then the data, address, and chip-select signals, 
after the hold times are met. 

There are two types of 1/O-read operations as well, and 
again they are determined by the Multimodule board. 
The first is a full-speed 1/0 read (Fig. 4). The base 
board generates a valid 1/0 address and chip-select and, 
after the set-up timings are met, it activates the IORD/ 
line. The Multimodule board must generate valid data 
from the addressed 1/0 port in less than 250 ns. The base 
board reads the data and removes the command, 


address, and chip-select signals as indicated in the timing: 


diagram. 

Read-with-wait, whose timing is at right in Fig. 4, is 
used by Multimodule boards that cannot perform a read 
operation under the full-speed specifications. The base 
board generates a valid address and chip-select, just as 
with a full-speed read. However, the Multimodule board 
now activates the MWAIT/ signal, which in turn removes 
the ready input to the base’s processor, putting it into a 
wait state. The processor activates the IORD/ signal 
before going into a wait state. 

The Multimodule board will remove the MWAIT/ sig- 
nal when valid data can be read from the data bus. After 
reading the data, the base board removes the command, 
address, and chip-select signals. 

The iSBX 351 serial 1/0 board is a good example of 
how easily large-scale integrated circuits may be inter- 
faced by the iSBX bus. It presents the iSBC 80/10B 


ADDRESS 
(MAg—-MA>) 


E VALID ADDRESS 


CHIP SELECT 
(MCS; ) 


WAIT 


1/0 READ 
(10RD) 


DATA BUS 


VALID DATA 
(MDo—MD>) ORR) 


FULL-SPEED 


board with a second serial port. 7 

The iSBC 351 board (Fig. 5) provides a synchronous. 
or asynchronous serial communications channel with 
programmable format and baud rates up to 64 kilobits 
per second. In the synchronous mode, the user selects via 
software the number and format of the synchronization 
characters and the number of data bits. Parity may be 
even, odd, or disabled. In the asynchronous mode, the 
number of data bits and stop bits, as well as parity 
generation and detection, may be specified under pro- 
gram control. The added channel is compatible with 
either the RS-232-C or RS-422/449 interface. 

Two additional 16-bit counters are on the board for 
other uses. Their mode of operation and count value may 
be written or read under program control. With the 
interrupt lines provided by the iSBX bus, they may also 
be used as real-time interrupt sources (see Table 1).- 

As stated earlier, an 8251A Usart gives the iSBX 351 
module a high-performance communications channel. In 
addition, an 8253 programmable interval timer (PIT) 
provides the three counters for clock generation and 
timing. Note in the block diagram of Fig. 5 that both 
devices are connected directly to the data, address, and 
command buses with no buffers. (Each chip, however, 
has its own chip-select line, preventing data bus conten- 
tion.) The absence of buffers keeps the parts count down 
and the speed up. | 

Also shown in the extra block diagram are two option- 
al lines that may be used as additional interrupt lines or 
to interface to the additional timer/counters. There are 
four interrupt sources on the board. Two, from the 
8251A, indicate either that a character has been received 


OQQQQOOOAKAK VALID DATA 


WITH WAIT STATE 


4. Read types. As in writing data into a Multimodule board, informationis read from it in one of two ways: full speed or read-with-wait. The wait 
state extends the length of time that data is valid. This is necessary for slower transactions such as analog-to-digital conversions. 
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5. More serial 1/0. The iSBX 351 serial input/output Multimodule board provides the base processor with an additional synchronous or 
asynchronous communications channel— one that is compatible with either the RS-232-C or the RS-422/449 interface specifications. 


for reading or that the transmitter buffer is empty and 
ready for transmission. Two other interrupts may be 
generated by the timer/counters: The timers count from 
an on-board crystal-controlled oscillator. 


Compatible with both 


The iSBX 351 module uses a unique split-edge con- 
nector to provide compatibility with both RS-232-C and 
RS-449 interfaces. RS-232-C is commonly used to com- 
municate with terminals, modems, and other equipment 
up to a distance of 50 feet away. RS-422 is a new 
interface that.allows high-speed data transfers of up to 
4,000 feet through differential lines that reduce noise 
such as crosstalk. The iSBX. 351 module is the first 
expansion board to offer both interfaces. 

The iSBX 351 module is programmed by a series of 
1/O-read and -write commands. Table 2 shows the 1/0 
port assignments on the iSBC 80/10B board by way of 
explaining the code sequences in Table 3 that run on it. 
The first routine in Table 3, INIT, initializes the 8251A 
for asynchronous operation and programs the 8253 to 
generate a baud rate.of 9,600. XMIT takes a character 
from the C register of the 8080A and sends it to the 
Usart for transmission. RECV gets a.character from the 
Usart and places it in the accumulator. Note that in both 
data-transfer routines the Usart status register is check- 
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ed to ensure proper operation. 

The iSBX 350 programmable 1/0 Multimodule board 
provides 24 general-purpose 1/O lines (or three 8-bit 
ports) via a standard 50-pin edge connector, giving the 
iISBC 80/10B a total of 72 1/0 lines. The 8255A is the 
only LSI component on the board, and six sockets are 
provided for line drivers or terminators. : 

Two bidirectional inverting 4-bit bus transceivers are 
provided for one of the three ports; sockets for the other 
two are TTL-compatible, allowing the use of inverting, 
noninverting, or open-collector drivers. When either of 
these other two ports is used as an input, the lines may 
be terminated either with 1-kilohm pullup resistor packs 
or with 220/330-ohm pullup/pulldown resistors. 


TABLE 1: iSBX 351 SERIAL INPUT /OUTPUT BOARD'S | 
ae RATES AND INTERVAL TIMES 


Minimum values Maximum values 


Baud 18.75 bauds 64 kilobauds 
generator (limited by 8251A) 


Dua} cascaded 
timers 
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TABLE 2: iSBX 351 ADDRESS ASSIGNMENTS 


ty 


Universal 
synchronous/ 
asynchronous 
receiver-transmitter 


FO, F2, F4, or F6 
F1, F3, F5, or F7 


data port 


control port 


F8 or FC 
F9 or FD 
FA or FE 
FB or FF 


counter O 
counter 4 
counter 2 


control port 


TABLE 3: SERIAL INPUT/OUTPUT ROUTINES 


Mode word to 8253 counter 2 


Divide value to 8253 counter 2 


Mode word to 8251A Usart 


Command word to 8251A 


Check Usart status to make sure it’s 
ready to transmit a character 


Loop until ready 
Get data character 
Send it 


Check Usart status to see if a new 
character has been received 


Loop until data is available 


Check framing, overrun, and parity 
error bits 


Jump to an error handler if there 
are any problems 


Get data 


The iSBX 350 module supports all three 8255A 
modes: basic 1/0, strobed I/O, and strobed bidirectional 
bus 1/0. Several of the handshaking signals are available 
as interrupt sources, and an additional external interrupt 
may be brought in via the edge connector. 

Programming this board is as simple as programming 
the 8255As on the iSBC 80/10B itself. First, a mode 
word Is written to the control port to specify the opera- 
tional mode for each port. Data transfer may then begin, 
in the form of 1/O-read or -write operations. 

The iSBX 332 module is an accurate 32- or 64-bit 
floating-point processor that performs arithmetic opera- 
tions in accordance with the proposed IEEE floating-point 
standard. It uses the 8232 floating-point processor. 

The math module uses one data format that has two 
word lengths of 32 or 64 bits. The board will add, 
subtract, multiply, and divide for both word lengths. 
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TABLE 4: COMMAND MNEMONICS OF iSBC 332 
FLOATING-POINT MATH MULTIMODULE 


SH a Command description! 


Add TOS to NOS. Result to NOS. Pop 
stack. 


Subtract TOS from NOS. Result 
to NOS. Pop stack 


Multiply NOS by TOS. Result to NOS. 
Pop stack. 


Divide NOS by TOS. Result to NOS. 
Pop stack 


Add TOS to NOS. Result to NOS. Pop 
stack. 


Subtract TOS from NOS. Result 
to NOS. Pop stack. 


Multiply NOS by TOS. Result to NOS. 
Pop stack. 


Divide NOS by TOS. Result to NOS. 
Pop stack, 


Clear status register. 


Change sign of single-precision operand 
on TOS. 


Change sign of double-precision operand 
on TOS. 


Push single-precision operand on TOS 
to NOS. 


Push double-precision operand on TOS 
to NOS. 


Pop single-precision operand from TOS. 
NOS becomes TOS. 


Pop double-precision operand from TOS. 
NOS becomes TOS. 


Exchange single-precision operands 
TOS and NOS. 


1. abbreviations: NOS > next on stack, TOS = top of stack 


Table 4 shows the instruction mnemonics and functions, 
as well as the positions in the stack (top of stack or next 
on stack) the operands and results occupy. 

The 8232 runs at 4 MHz for maximum throughput. A 
multiplication of two 32-bit quantities takes about 50 
microseconds, excluding data entry and retrieval. In 
addition, two interrupts signal the base-board processor 
of completion of an operation or an error. 


Floating-point math 


The two word lengths of the floating-point standard 
were chosen for the highest speed and accuracy. If speed 
is the primary objective, the 32-bit format gives a 
dynamic range of approximately 10-8 to 10*8. If range 
and accuracy are required, the 64-bit format spans in 
excess of 10*3° to 103°. This wide dynamic range, in 
conjunction with highly accurate rounding algorithms, 
renders the iSBX 332 module ideal for scientific prob- 
lems and other applications requiring high speed, accu- 
racy, and range. LJ 
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MULTIPROCESSING SYSTEM MIXES 
8- AND 16-BIT MICROCOMPUTERS 


Combining different single-board computers on a single 
bus and assigning to each the tasks most suited 

enable a cost-effective multiprocessing system configuration 
with improved throughput and reliability 


Joseph P. Barthmaier 


Intel Corporation, Hillsboro, Oregon 


I wo or more single-board computers can sHous a com. 


mon system bus to provide improved performance; « vor 


reliability, and cost-effectiveness in medium to: large 


scale applications. Interfacing multiple computers across _ 
a system bus affords a dual-bus architecture in which 
global system traffic is isolated from local traffic on the’ 
board buses. This allows a straightforward design of | 


modular ‘multiprocessing systems that combines different 
computer boards, and allocates to each that portion of 
the overall system function to which it is best suited. 

In a typical design, 8- and 16-bit single-board com. 
puters (SBCs) communicate across a system bus to ser- 
vice an application that requires both realtime data ac- 
quisition and extensive signal processing. Partitioning 
system tasks and assigning each to the appropriate sBC 
optimizes performance without adding components. Dual- 


port memory provides a convenient way to synchronize 


'. processes on different sBcs. Because most system func: 
~ tions are isolated on one ssc, reliability and throughput 
- are increased, and implementation is facilitated. 

. Single-Board Computer Concept 


In earlier SBC design, the fundamental goal was to pro- 


vide a board containing all the resources required for a 
large variety of microprocessing applications. A typical 
processor board supplies. an 8080A processor, 4k bytes 
of random access memory. (RAM), sockets for up to 8k 
bytes of erasable programmable: read only memory /read 
only memory (EPROM/ROM), a serial input/output (1/0) 
interface, 48 parallel 1/o lines, three timer/counters, and 
eight levels of priority interrupt. With this hardware 
configuration, many small applications can be served 


with no need for additional memory or digital logic. 
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SINGLE-BOARD COMPUTER 


Single SBC system with 
two expansion boards. CPU 
uses data path 1 to access 


MEMORY WO 
EXPANSION EXPANSION 
BOARD BOARD 


‘}-ONBOARD 
BUS 


@ 


local memory and 1|/O, and 
data path 2 to access expan- 
sion boards on MULTIBUS sys- 
tem bus 


soon MULTIBUS™ SYSTEM BUS > 
aes 


Because larger applications require additional re- 
sources, an external bus structure was defined. The 
MULTIBUS'™ system bus was designed for communication 
hetween SBCs and system expansion boards. Address, data, 
and handshake lines were defined for memory and 1/0 
transfers between sBCs and expansion boards. There are 
bus expansion boards for system expansion in areas of 
RAM and ROM storage, serial and parallel 10, analog 
1/0, and peripheral controllers. 

In Fig 1, two buses interconnect a system with an sBc 
and two expansion boards. An onboard bus accesses 
local resources, and. the system bus accesses global re- 
sources. A key advantage of this structure is that an SBC 
may not require the system bus for a large portion of its 
memory or IO transactions. In many applications, less 
than 10°¢ of the time is taken by system bus accesses. 
The large amount of potential system bus capacity makes 
this architecture a natural candidate for multiprocessing 
applications. As additional sBcs are included in the sys- 
tem, the incremental amount of system bus bandwidth 
required is usually small. 


Motivations for Multiprocessing 


Certain system applications benefit from using more than 
a single ssc. Motivations for constructing multiprocessing 
systems with spcs include: 

Resource sharing. In a multiprocessing system designed 
around the resource sharing concept, two or more pro- 
cessor boards share a common resource, such as a high 
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speed mathematics board or a_ peripheral controller. 
These boards perform independent functions with no 
relationship to one another except for the shared re- 
source. Low cost is the obvious motivation for using a 
resource sharing multiprocessing configuration. If two 
processor boards share the same diskette controller, for 
example, overall system costs are considerably reduced. 


Enhanced system throughput and performance. In many 
applications, significant improvements in performance 
may be achieved by using more than one processor in 
the system. Two ways of allocating or partitioning sys- 
tem functions among multiple processors, such as pipe- 
line and parallel partitioning, are shown in Fig 2. In pipe- 
line partitioning, system functions (tasks) are divided 
among several processors, so that data flow through the 
system is primarily serial. Each processor performs its 
portion of system functions, and then calls’ upon an- 
other processor to perform another set. An example of 
pipeline partitioning is when one processor performs 
data acquisition and buffering, while a second uses the 
data to perform digital signal processing. 

Parallel partitioning allocates system functions among 
several processors in such a way that each processor per- 
forms a separate system task in parallel. An example is 
a system where one processor performs an_ industrial 
process control loop, while another monitors and con- 
trols a varying parameter, such as temperature. 

Few systems may be characterized as totally parallel 
or pipeline partitioned; but designating systems in this 
manner can often be helpful during the system design 
phase, particularly when interprocessor communication 
software is being designed. 


Modularly configured systems. A primary design goal, 
particularly in systems that are produced in low volume, 
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SINGLE PROCESSOR PIPELINE PARTITIONING 
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is often flexibility of system configuration. Using modu- 
larly configured systems, independent hardware and soft- 


ware modules are designed and implemented with indi- 


vidual processors or intelligent slave boards. When a 
particular ‘configuration is required, the system designer 
selects the necessary hardware and software modules and 
combines them: with interprocessor communication soft- 
ware. Shortened system development time, simple debug- 
ging, ‘and a convenient upgrade path for system. expan- 
sion are the benefits of such a technique. 


High reliability. Multiprocessing may be used to ‘diate 
system tasks on individual processors in .applications 
where a high degree of reliability is a requirement.- If 
a processor: fails; the remainder of the system continues 
to operate. Redundant designs, where ‘a second processor 
may be dynamically assigned. to perform the functions 
of a disabled processor, are a’ possibility. 


Multiprocessing With | 
Single-Board Computers 


The MULTIBUS snehiiectaral aegis facilintes ules 
sing because multiple bus masters are accommodated, 
bus-masters generate and acknowledge .bus interrupts, 
and dual-port memory and intelligent. slave architecture 
can be implemented. 


vee Bus Masters | | 
A bus master is a dynamic: board that takes control of 
the bus by asserting address and control lines. Only one 


bus master may control the bus at any given moment. 
Examples of bus masters include single-board computers 


PARALLEL PARTITIONING 


Fig 2° Pipeline and parallel 
‘partitioning. Single processor 
A performs tasks X, Y, and Z. 
Pipeline partitioning among 
_three processors allows pro- 
cessor B to perform task X 
and pass result to processor 
C; processor C to perform 
task Y .and pass result to 
processor D; and processor D 
to perform task Z. Each pro- 


cessor except first must wait 
for input data generated as 
output from another processor. 


Parallel partitioning allows 
each processor to perform its 
task independently 


and direct memory access. (DMA) controllers, .A bus 
slave is a passive element on the bus that. does not.assert 
address and control lines. Examples of bus slaves include 
memory or 1/0 expansion. boards and intelligent. slaves. 
_ Several control lines exist on the bus.so that potential 
bus masters can exchange control. These control lines, 
plus logic on the. master boards, implement, a priority 
scheme in which the highest priority master requesting 
the bus obtains control. There are two priority. resolution 
schemes for exchange of the bus, serial and. parallel. Us- 
ing serial priority: resolution, there may be up to three 
bus masters in the system: the parallel technique .allows 
up to 16. A bus master is always given. the opportunity 
to complete a bus transaction before being. preempted by 
a higher. priority master.,In addition, bus masters may 
retain control of the bus by “locking” the bus. The bus 
lock feature is required when a master must have ex- 
clusive control of the -bus. for such functions as testing 
and setting software semaphores and completing opera- 
tions involving 1/0 devices. 

Since sBCs have extensive onboard resources, system. 
bus transactions are not required for all 1/0 and memory 
accesses. Depending on the application and system design, 
multiple bus master .systems.. with a small number. of 
transactions can be configured. The system design goal 
is to use onboard resources whenever possible. Frequently 
executed or time critical code should be stored in on- 
board memory to minimize system bus accesses and to 
avoid delays while contending for the bus. 


Interprocessor Interrupts 


Eight interrupt lines exist on the system bus. In addition 
to interrupts from 1/0 slave -boards or. DMA. controllers, 
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these interrupt lines can be used for communication be- 
tween master sBC boards. Individual master boards may 
either generate interrupts or be interrupted from one or 
more of the interrupt lines. Interprocessor interrupts pro- 
vide a fast and effective way for multiple sBcs to com- 
municate over the system bus. 


Dual-Port Memory 


Single-board computers have been designed with onboard 


RAM containing two access ports. Dual access ports per- 
mit the onboard cpu to access the RAM directly using the 
onboard bus. Other sscs also access the RAM using the 
system bus. The amount of memory available for system 
bus access may be selected from all memory accessible to 
no memory accessible, in increments of one-half or one- 
quarter of available memory size. This ability to block 
RAM access from the system bus provides memory pro- 
tection for data and code stored in those nonaccessible 
areas of the dual-port RAM. Fig 3 illustrates an example 
of two SBCs accessing the dual-port memory of one SBC. 

Two important benefits are gained by using the dual- 
port architecture. First, in a multiple-processor system, if 
two processors communicate through shared memory, 
only one must..access the memory using the system bus, 
and the amount of system bus traffic may be significantly 
reduced. Second, in a multiprocessor configuration where 
limited RAM storage is required, a separate memory 
board is not needed. Such small systems have all the 
required system bus-accessible memory on one or more 
of the SBCs. Mee 35 


Intelligent Slave Architecture 


To distribute intelligence in larger systems, the intelligent 
slave concept was: developed. An intelligent slave is a 


86/12A BOARD 


{80/05 BOARD 


board that contains a Cpu, some dedicated 1/0 capability, 
and a dual-port RAM for interfacing to the system bus. 
For example, the issc 544°” intelligent communications 
controller contains an 8085A processor, four 8251A 
serial 1/0 devices universal synchronous/asynchronous 
receiver /transmitters (USARTs), 12 levels of priority in- 
terrupt, and 16k of dual-port RAM. All communication be- 
tween a master processor board, such as an isBc 86/12A™™ 
board, and the 544 takes place using the 544 dual-port 
RAM (Fig 4). The 8085A processor does not have the 
capability of taking control of the system bus (becoming 
a bus master) and accessing other system resources. 

The 544 board was designed to operate using only 
onboard resources. The master SBC in the system transfers 
blocks of data and parameters to or from the 544 using 
the onboard dual-port RAM. To facilitate communication 
with the 544, an interrupt occurs when a master SBC 
writes into the lowest byte of memory of the dual-port 
RAM. The intelligent slave board can interrupt a master 
spc by asserting one of the system bus interrupt lines 
with an I/O instruction. The address space occupied by 
the dual-port RAM may be set anywhere within 1M bytes; 
2() address bits are decoded. 

Primary advantage of intelligent slave architecture is 
the ease with which multiprocessing applications may be 
implemented. The intelligent slave may be sent a buffer 
of data and commands with an interrupt occurring, via 
a write to the lowest byte of memory, as a start command. 
The master SBC may continue operation with other func- 
tions to be notified, via an interrupt or a status byte in 
dual-port RAM, when the slave has completed a task. Since 
the intelligent slave may not access system resources via 
the system: bus, no interference with the master SBC can 
occur. 


issc and the combination of ispc and a numerical suffix 2 are reg: 
istered trademarks of Intel Corp 


~Fg3 Dual-port memory archi- 
tecture. 8086 microprocessor 
on 86/12A uses dual-port con- 
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troller to access onboard RAM. 
8085A on 80/05 accesses this 
same RAM across system bus. 
Different configurations allow 
8085A access to part or all 
of dual port memory 
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Fig 4 Intelligent slave archi- 
tecture. 86/12A and intelligent 
slave board 544 communicate 
using dual-port RAM 
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The 86/12A Board 


The isc 86/12A single-board computer! has many of the 
architectural features of 8-bit boards (serial. and parallel 
1/0, multiple interrupt levels, and timer/counters) but 
includes a 5-MHz 8086 microprocessor and_ larger 
amounts of RAM and EPROM/ROM storage. The 16-bit 
8086 permits byte and word transfers, hardware multi- 
ply/divide, 1M-byte addressability, extensive string ma- 
nipulation instructions, and many other features. The 
86/12A contains 32k bytes of dual port RAM and sockets 
for up to 16k bytes of EPROM/ROM, doubling the memory 
available on previous boards. If more RAM or EPROM/ROM 
storage is required, memory expansion modules permit 
doubling RAM and/or EPROM/ROM storage to 64k bytes 
of RAM and 32k bytes of EPROM/ROM. 


Memory expansion modules are small printed circuit 


boards that attach to the 86/12A board using sockets and 
nylon bolts. Use of the expansion modules is advan- 
tageous from a price/performance point of view. Price 
of either of the memory expansion modules is significant- 
ly less than that of an equivalent separate memory ex- 
pansion board with its own system bus interface and 
support circuitry. Memory expansion modules also offer 
higher performance since it is not necessary to use the 
system bus for memory transactions. All transactions 
take place using the onboard bus with no additional 
wait states or bus contention. 


8- and 16-bit MULTIBUS Compatibility 


The 8086 microprocessor performs 8- or 16-bit transfers 
to or from memory or 1/0 devices. When a byte (8-bit) 
transfer is requested from an even address, data are pre- 


sented to the microprocessor on its low order data lines, 
DO through D7. When a byte transfer is requested from 
an odd address, data transfer must occur on the high 
order data lines, D8 through D15. When a 16-bit (word) 
transfer is requested, data are transferred on all 16 data 
lines, DO through D15. When an 8-bit microprocessor 
(8080A or 8085A) is used, however, all byte transfers 
must take place on data lines DO through D7, the only 
lines available. 

To maintain compatibility between boards with 8-bit 
and 16-bit processors, a system bus transfer protocol has 
been developed where all byte transfers, regardless of 
whether from an odd or even address, take place on 
the low order system bus data lines, DATO/ to DAT7/; 
word transfers, however, use all 16 data lines, DATO/ to 
DATF/. To accomplish these byte transfers, an 8-bit 
buffer is used on 16-bit master and slave boards for trans- 
ferring data from the high order data lines on the board 
to the low order data lines of the system bus. An addi- 
tional signal line, byte high enable, (BHEN/) indicates 
whether a word transfer is taking place on the high order 
and low order data lines or whether a byte transfer is 


taking place only on. the low order data lines. Fig 5 


illustrates 8- and 16-bit transfers and the use of the ad- 
ditional buffer for transferring the signal to or from the 
high order data byte. | 


Multiprocessing System Example 


A data acquisition and signal processing system design 
demonstrates the capabilities of a multiprocessing system, 
where improved performance is mandatory. General ap- 
plication of the system is power spectrum analysis of. 


_ vibration and acoustic signals. Application areas for such 
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Fig 5 Three mechanisms for 
byte and word transfers. All 
byte transfers use DATO to 
DAT7. Only word transfers use 
high order bus lines DAT8 to 
DATF. Slash (/) after name 
indicates active low signal 
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systems include vibration analysis in mechanical struc- 
tures such as electric motors, automobiles, aircraft, and 
buildings, as well as ee sonar, and low frequency 
radar analysis.. 

Design objective is to molten the condition of large 
electric motors. Power spectra of vibration signals from 
various points on the motor are calculated in order to 
detect bearing wear and to predict an impending motor 
failure. Calculated power spectra are compared with ref- 
erence spectra, and, if thresholds in various regions of 
the spectra are exceeded, an operator alarm is activated. 
Information regarding the state of the motors and the 
reference spectra is stored on disc. 

The system monitors 16 channels of analog input sig- 
nals generated by pairs, of accelerometers mounted on 
each of eight motors. Sampling and calculations for the 
two channels of a single motor are performed simulta- 
neously; then the next motor in sequence is monitored. 

last Fourier transform (FFT) of a buffer of samples 
from an analog to digital converter (ADC) performs 
power spectrum calculations... Real and imaginary. parts 
of the FFT results are squared and summed to form a pow- 
er spectrum that is compared to the reference power spec- 
trum in order to determine if the motor vibrations are 
within acceptable tolerances. A CRT displays calculated 
and reference power spectra. At periodic intervals, data 
are stored on disc for archiving the condition of each 
of the motors. If the motor spectra exceed the reference 


16-BIT 
DATO/ - DATF/ 
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spectra, the crT display and a control panel indicator 
alert the operator. 


System Hardware 


As shown in Fig 6, the 711 analog input beard: contain- 
ing a 12-bit ADC, samples the 16 analog signals from the 
motors. The 80/05 processor board drives the 711 analog 
board and handles all system data acquisition activities. 
The 80/05 contains an 8085A CPU, 512 bytes of RAM, up 
to 4k bytes of. EPROM/ROM, a timer/counter, parallel and 
serial 1/0'lines, and four levels of priority interrupt. The 
86/12A board is: the main system processor. The 8086- 
based board performs all the signal processing functions, 
displays the spectra on the crT, drives the system control 
panel, and transfers motor condition data onto disc using 
the 204 single-density diskette controller. 

Increased system performance is the design motivation 
for using two processor boards. The 86/12A board, with 
its 5 MHz 8086 cpu, 16-bit multiply/divide capability, 
64k bytes of dual-port RAM, and 32k bytes of EPROM/ROM, 
is used for the faathemacally intensive power spectrum 
calculations. 

The 80/05 processor board is used to . offload Tia 
acquisition activities from the main processor. It assumes 
all the overhead of handling the 711 analog board. Sam- 
pling is performed at 250-us intervals using the onboard 
timer; data from the two channels are scaled, demulti- 
plexed, and stored in a buffer. The 8-bit processor board 
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was chosen for this function because it had the necessary 
onboard resources, yet was low in cost. Throughput per- 
formance improvements of up to 40% can be achieved 
using this 2-processor approach. 

The 80/05-711 combination assumes the role of an 
intelligent analog subsystem, when viewed by the 86/12A 
processor. The 86/12A sends the 80/05 commands via 
a parameter block, and the 80/05 collects the data samples 
in buffers. When a buffer is complete, the 80/05 signals 
the 86/12A using the parameter block. Thus, the 80/05 
acts as an intelligent DMA controller for the 711 board. 


System Software 


Due to the large RAM requirements of the system, the 
isBc 300'” RAM expansion module is used to increase RAM 
capacity to.64k bytes. Memory has been configured to 
make 16k bytes of memory accessible to the system bus, 
with the remaining 48k bytes reserved for -use by the 
onboard 8086 and not accessible to the system bus. The 
amount of 86/12A dual-port RAM that is system bus. ac- 
cessible may be configured in 16k increments from zero 
(no memory accessible) to 64k (all memory accessible). 
The parameter block used for interprocessor communica- 
tion and a pair of buffers used for storage of the analog 
samples are stored in the memory accessible to the 80/05. 
Memory not accessible to the 80/05 contains the data and 
buffers used for the calculated averaged. power spectra, 
reference spectra, CRT displays, and disc data. The 16 
bytes of the parameter block contain all information re- 
quired for communication between the two SBCs in the 
system, including buffer addresses, status, size, pare 
rate, and start and end channel. 

Fig 7 is a flow diagram illustrating how buffer state 
bytes are used to synchronize the filling and processing 
of the data buffers. Each buffer may be in one of two 
states, FULL or EMPTY. Initially, both buffers are EMPTY. 
At initialization, the 80/05 fills buffer 0, sets its status 
to FULL, fills buffer 1, sets its status to FULL, and waits 


aay Fig 6 -Data acquisition and 
Og Signal analysis system. 80/05 
BOARD drives 711 to handle all data 


acquisition functions while 86/ 
12A performs signal analysis, 
operator interfacing, data stor- 
age, and data retrieval func- 
tions 


for buffer 0 to become EmpPTY. It then fills buffer 0, sets 
its status to FULL, waits for buffer 1 to become EMPTY, 
etc. Initially, the 86/12A waits for buffer 0 to be FULL, 
processes it, sets its status to EMPTY, waits for buffer 1] 
to be FULL, etc. Using this simple technique, the two 
processors synchronize each other with a minimal amount 
of overhead. 

The parameter block approach is used to provide a 
simple means for interfacing the two sBcs. At system in- 
itialization, the 80/05 board needs only to know the base 
address of the parameter block. Once this is known, all 
other information required for the 80/05 to function 
properly is available. The end application and even the 
specific type of sBc that calls upon the 80/05 for data 
samples remain irrelevant to the 80/05. Driver software 
for the 80/05 is therefore highly modular and may be 
used in a variety of applications and configurations with 
no changes required. . 

A key capability of this system design is that the 
86/12A board does not use the system bus to access data 
samples, thus minimizing execution time for the highly 
iterative FFT computation. The 80/05 processor takes 
the samples from the analog board and stores them di- 
rectly into the 86/12A dual-port memory. Therefore, ex- 
cept for occasional disc transfers by the 86/12A, the 
80/05 is the only processor using the system bus. This 
increases system throughput - and eliminates contention 
for the system bus. 


Signal Processing Software 


The .algorithm used for the FFT in this application is 
known as “time decomposition with input bit reversal.’” 
Using this algorithm, an in-place FFT has been pro- 
grammed for an input frame size of 128 complex points. 
Sixteen-bit integer mathematics is used for all internal 
calculations of the FFT. The 86/12A board computes the 
128-point complex FFT in 110 ms. Computation of the 
averaged power spectra is performed using a double pre- 
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Fig 7 Synchronization of two SBCs. Buffer status bytes are used in shared parameter block. 
Simple semaphore mechanism is natural extension of double buffered acquisition technique 


cision integer format. The 16-bit integer real and imagi- 
nary values which result from the FFT are squared and 
summed to obtain a 32-bit power spectrum. Thirty-two 
frames of data are processed and summed to form the 
averaged power spectrum. 


Summary 


Two reasons for the slow growth of multiprocessing have 
been the limited selection of sBcs and the relatively small 
application base. These conditions are changing rapidly 
due to the large number of sBCs now available. These 
boards contain dual-port RAM and newer 8- and 16-bit 
cPUs, and provide system designers with a comprehensive 
set of tools for tackling applications that require the 
power of multiprocessing. Thus, the sBc application base 
has grown significantly in recent years. 

The system application combines a low cost 8-bit sBc 
and a high performance 16-bit sBc in a configuration 
designed for both data acquisition and signal analysis. 
The 8-bit sBc relieves the 16-bit spc of all system data 
acquisition functions. Because the 16-bit board spends 


1-265 


full time processing data, system throughput can be in- 
creased by as much as 40%. 
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INTRODUCTION | 


A large number of microcomputer applications 
require the ability to respond to events in real time. 
RMX/80 provides the system software around 
which you can build a real-time multitasking appli- 
cation on Intel SBC 80 Single Board Computers. 
In addition, RMX/80 increases the utilization of 
a Single Board Computer by allowing its resources 
to be shared among several tasks executing concur- 
rently. Synchronization of these multiple real-time 
tasks is handled by RMX/80, freeing you to con- 
centrate your major programming efforts on your 
application. 


This application note begins with an overview of 
RMX/80. Readers who are familiar with the mate- 
rial presented in the RMX/80 User’s Guide may 
choose to skip to the next section, a description of 
how to use RMX/80 and the steps involved in 
using it by describing two applications. 


e An interrupt driven minimal terminal handler 
for a CRT or Teletypewriter. 


@ A closed-loop analog control subsystem utiliz- 
ing the Intel SBC 711 analog-to-digital board. 


Each example has diagrams illustrating the rela- 
tionships between its tasks and exchanges. These 
are useful tools in conceptualizing the activities 
taking place in real time. Program listings of the 
applications are interspersed with text describing 
the application. 


OVERVIEW 


Real-time systems provide the ability to control 
and respond to events occurring asynchronously 
in the physical world. Later in this application 
note, a process control application is described 
that monitors and controls the temperature within 
several chambers. The system controls the process 
by simply turning on and off a heat source. The 
system could also display the temperature on an 
operator’s console and permit entry of new set- 
point temperatures and error ranges. 


A single large program could have been used to 
perform the functions in a sequential manner. 
However, this approach may not permit an opera- 
tor to enter control variables at the same time the 
process is being monitored and controlled. In 
contrast, real-time systems do not operate sequen- 
tially. A number of events may all be happening 
at the same time. This concurrence of events is a 
distinguishing: characteristic of real-time systems. 
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BASIC CONCEPTS | 


There are basically three concepts that the user 
must master to effectively use RMX/80. The first 
is the task, an independent program which com- 
petes for resources within the system. The second 
concept is the message. Messages convey data and 
synchronization information between tasks. The 
third concept is the exchange. An exchange enables 
one task to send a message to another. As we will 
see later, the interaction between tasks and ex- 
changes enables the user to implement mutual 
exclusion, communication, and synchronization. 
Mutual exclusion is a technique that controls 
access to a shared resource such as an I/O device 
or a data structure. | 


Task 


Under RMX/80, the user codes a separate program, 
known as a task, for each event. An arbitrary num- 
ber of these tasks execute concurrently and are 
subject to synchronization as required by their 
functions. Tasks share resources such as data struc- 
tures and can communicate between themselves. 


Message 


A message is a unit of communication between 
tasks. Together with the exchange mechanism, it 
conveys information between tasks and can syn- 
chronize their operations. 


Exchange 


RMX/80 uses message sinus for task-to-task 
communication. An exchange is a pair of queues 
represented by a data structure at which messages 
are left by one task to be picked up by another. 
Tasks may send messages to an exchange, and may 
wait for messages at an exchange. A task which 
waits for a message may perform a timed or an 
untimed wait. A timed wait will terminate upon 
the receipt of a message or at the end of the speci- 
fied period of time, even if it has not received a 
message. When a task does an untimed wait for a 
message it is guaranteed that the task will not exe- 
cute again until a message is available for it. A 
representation of the exchange data structure is 
shown in Figure 1. | 


GENERAL CHARACTERISTICS 


In addition to the basic concepts of fate and ex- 
changes, several other general characteristics of 
RMX/80 are relevant in this overview. 7 


AFN-01931A 


Figure 1. Exchange Data Structure 


System Time Unit 

RMX/80 uses a system time unit that is the period 
of time between “ticks” of the system clock. The 
standard RMX/80 system time unit is 50 milli- 
seconds. The system time unit provides timing and 
user task scheduling. A task may wait at an ex- 
change for a specified number of system time 
units and then continue execution. A task could 
be written to generate messages at specific time 
intervals. Tasks) waiting for the messages would 
then be scheduled according to those time intervals. 


Message Producing/Consuming Tasks 


In general, tasks can be classified as message pro- 
ducing or message consuming tasks. The processing 
flow of these types of tasks are usually cyclic i in 
nature ane can be shown as follows. 


TASK ENTRY POINT TASK ENTRY POINT — 


INITIALIZE TASK INITIALIZE TASK 


WAIT FOR REQUEST PERFORM FUNCTION 


INITIALIZE OPERATION 


EER ROpe loners . (SEND MESSAGE) 


SEND RESPONSE WAIT FOR RESPONSE 


CONSUMER 


PRODUCER 


Figure 2. Message Producing/Consuming Tasks 


A consumer task waits for a message to be posted 


at a particular exchange and takes control of the 


processor only when. it has received a message and 
no other tasks of higher priority are ready to exe- 
cute. The consumer task performs some action 
based upon the message and then simply resumes 
waiting until the next message is received. Usually, 
the consumer task acknowledges completion of 
its function by sending a response message to some 
other exchange associated with a task. | 
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A producer task initiates its function by sending 
a message to another exchange and then surrenders 
control of the processor. The task continues to 
wait until it receives a response to its message. 


Notice that the distinction between these types 


of tasks is relative since most tasks both produce 
and consume messages. However, the producer/ 
consumer concept helps clarify the general struc- 
ture of tasks—tasks are typically programmed 
loops. A producer task performs a function, sends 
a message, waits for a response, then loops back to 
begin again. A consumer task waits for a message, 
performs a function, sends a response, then loops 
back to wait again. 


Interrupts 


Hardware interrupts are treated as messages from 
peripheral devices for which a task can wait, as if 
the interrupt were a message from some other task. 
These messages arrive at particular exchanges, 
called interrupt exchanges, but are otherwise treated 
as described above. The system provides the abil- 
ity to mask particular interrupts so that no mes- 
sages ever atrive at a particular interrupt exchange 
associated with the masked interrupt. In the event 
that the overhead associated with turning an inter- 
rupt into a message is too high, the interrupt can 
be treated by the user directly via a user supplied 
interrupt service routine. 


Task States 


Tasks may exist in a number of states. A task is 
running if it actually has the processor executing 
instructions on its behalf. A ready task is one that 
could be running (any wait for a message or time 
period has been satisfied), but a higher priority 
task is currently running. A task is waiting if it 
cannot be ready or running because it is waiting 
at an exchange for a message. A suspended task is 
one that is not permitted to run or compete for 
system resources until it is resumed. The rela- 
tionships between the task states are illustrated in 
Figure 3. 


Priority 

Each task has associated with it a priority that in- 
dicates its importance relative to other tasks in 
the system and relative to the interrupts of peri- 
pheral devices. RMX/80 schedules a task for exe- 
cution based on the task’s priority. Whenever a 
decision must be made on which task should be 
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run, the highest priority ready task is chosen. Each 
of the eight hardware interrupt levels has a set of 
priorities, one of which must be assigned to the 
task that services the interrupt. When an interrupt 
occurs that task is executed if it is the highest 
priority ready task. At the time a higher priority 
task preempts a lower priority task, RMxX/80 
saves all the relevant information about the pre- 
empted task so it can eventually resume execution 
as though it were never interrupted. This process 
is known as a context save. 


RUNNING 


SUSPENDED 


WAITING 


Figure 3. Task States 


NUCLEUS OPERATIONS 


The RMX/80 nucleus provides several operations 
that you can access with programmed calls. Two 
basic operations are covered in this section (addi- 
tional operations are described in the RMX/80 
User’s Guide): 


@e RQSEND, send a message to an exchange 
e RQOWAIT, wait for a message or time interval 


These two operations provide the capability to 
pass messages between tasks in a system running 
under RMX/80. 


Message Format 


The messages used by the send and wait operations 
to convey information between tasks are variable 
in length and contain the information shown in 
Figure 4. 
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(BASE) 


+indicates optional 


on OF BP NY © 


Figure 4. Message Format 


Fields 


1. LINK — a 2-byte field used to enter the mes- 
sage on a linked list at an exchange. 


2. LENGTH — a 2-byte field containing the total 
length of the message in bytes. The minimum 
message length is 5 bytes (LINK, LENGTH, 
and TYPE). 

3. TYPE — a 1-byte field indicating the type of 
message. 


4,.HOME EXCHANGE — an optional 2-byte 
field containing the address of an exchange to 
which this message should be sent when it has 
no further use. This field is very useful in im- 
plementing and managing a pool of messages. 


5. RESPONSE EXCHANGE — an optional 
2-byte field containing the address of an ex- 
change to which a logical response to this 
message should be sent. This field is intended 
to specify the exchange at which a sending 
task is waiting for an acknowledgement 
message if one is needed. 


6. REMAINDER — an optional field of arbi- 
trary length that may contain any data por- 
tion of the message. 


Sending a Message to an Exchange 


The RQSEND operation enables a task to post a 
message at an exchange. When you send a message 
to an exchange, RMX/80 actually posts only the 
address of the message at the exchange, not the 
body of the message. RMX/80 avoids the overhead 
required to move an entire message to an ex- 
change. Thus it is possible to queue a number of 
messages at the same exchange with little overhead 
in either execution time or memory requirements. 
When a task sends a message to an exchange, sev- 
eral functions are performed. 
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e The message is Puce < on _ ae CX-. 


change. 


e If there are one or more aad waiting at the 
exchange, the first task is given the message 
and is made ready. . 


e if a higher priority task is thereby made 


ready, the sending task loses control until 
it once again becomes the highest priority 
ready task. 


After a message is sent to an exchange, it must not 
be modified by the sending task. A task which then 
receives the message by waiting at the exchange 
where the message has been posted is free to modi- 
fy the message. The format of the RQSEND opera- 
tion is as follows. 


RQSEND(exchange-address,message-address) 


Message exchanges are defined by the user, and are 
normally addressed symbolically. For example, 
the exchange used: to pass readings from an analog- 
to-digital (A/D) task might be named ATODEX. 
The reading itself could be contained in a message 
with the name RDNG. Thus, a typical call for a 
send in a PL/M program might be as follows: 


CALL ROSEND (.ATODEX,.RDNG) ; 
The call procedure in assembly language is as 
follows. 


LXI  B,ATODEX » 


LX! D.RDNG 
CALL ROSEND 


The see language rules foe passing parameters 
to RMX/80 are the same as for passing. parameters 
to a PL/M procedure called from an assembly lan- 
guage module. For 2-byte parameters, the first 
parameter is passed in the:B and:C registers; the 
second parameter is passed in the D and E registers. 


Waiting for a Message or Time Interval 

The RQWAIT operation causes.a task to wait for 
a message to arrive at an exchange. It is also pos- 
sible to delay execution of a task when no message 
is anticipated for the task. The task simply: waits 
for the desired time period at a.message exchange 
where no message is ever sent. When a task waits 
for a message at an exchange Severe Operations 
are performed. mv 8 
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@ The task is made to wait: until a. message is 
sent to the specified: exchange, or until the 
time limit has expired. . ig 


. e When a message is available, its address is 
a - returned t to the task. 


© If the time limit expires heros a message 
becomes available, a system TIMES$OUT mes- 
sage is returned to the task. 


The format of the RQWAIT operation is as follows. 


ROWAIT(exchange-address,time-limit) 


The time limit is entered as some number of sys- 
tem time units (50 milliseconds); a l-second wait 
is equal to 20 time units. If zero is specified the 
wait is not timed, producing an indefinite wait 
until a message is actually sent to the exchange. 
Note that .a specified wait of five time units may 
sometimes only produce an actual wait of four 
time units. This can occur if you enter a wait 
immediately before the clock “ticks.” In this 
case the count would be decremented immediately 
after entering the wait. Only four full time unit 
periods would lapse before completion of the 
wait. Thus a user who wishes to ensure that at least 
five time units are spent in an asynchronous wait 
must specify six time units in the wait operation. 
A task which waits synchronously to the system 
clock, i.e., performs repetitive timed waits, does 
not have this problem because a new wait is exe- 
cuted following a tick that satisfied the previous 
wait. The following are typical calls for the 
aaa operation. | 


PL/M _ 
tie aaa ATODEX, aN 


The ROWAIT | arssetans returns an address value 
which is the address of amessage. © 


Assembly Language | 
-LXI -B,ATODEX 

LX] D,20 

. CALL: ° ROWAIT 


The ade nee of a message is ened in the HL 
register pair. : 
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Send — Wait Interaction 


To a large extent, the power of RMX/80 as a pro- 
gramming tool is derived from the interaction 
between send and wait. The interaction includes 
three multi-tasking operations. 


e Communication 
e Synchronization 
e Mutual Exclusion 


In describing these operations, a graphic notation 
for diagramming tasks, exchanges, and their 
interaction (send and wait operations) is useful. 
The notation is described in the next section on 
communication. 


Communication. The most common interaction 
between tasks is that of communication — the 
transmission of data from one task to another 
via an exchange (Figure 5). 


Figure 5. Communication 


Rectangles designate tasks while circles represent 
exchanges. Arrows that are directed from tasks to 
exchanges indicate send operations. Wait opera- 
tions are shown by arrows directed from exchanges 
to tasks. 


Figure 5 shows an example of communication 
between task A and task B. Task A sends a message 
to exchange X and task B waits for a message at 
that exchange. Task A is the message producer 
and task B the message consumer. | 


Synchronization. At times there is a requirement 
to send a synchronizing signal from one task to 
another. This signal can take the form of a message 
that contains only header information, that is, 
LINK, LENGTH, and TYPE. 


Let us consider the implementation of a task 
scheduler, used for the purposes. of synchronizing 
another task that performs a particular function 
at periodic intervals. The relationship between the 
tasks and exchanges is shown in Figure 6. | 
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Figure 6. Synchronization 


Task A, the scheduler, performs a timed wait on 
the X exchange. Note that the full wait period 
will always occur because there is no task that 
is sending messages to exchange X. In this manner, 
a specific timed wait by task A precedes the pass- 
ing of a synchronization message from task A to 
task B via exchange Y, and then the return from 
task B to task A via the Z exchange. 


If task B waited on X directly, rather than using 
task A for scheduling, it would be scheduled n sys- 
tem time units from when it waits instead of n 
units from the last time it was awakened. A com- 
parison between the two methods is shown in 
Figure 7. 


TASK B WAITING DIRECTLY ON X TASK A SCHEDULING TASK B 


Figure 7. Scheduling Methods 


Mutual Exclusion. In an environment with multi- 
tasking, resources often must be shared. Examples 
of shared resources include data structures. and 
peripherals such as the Intel SBC 310 Math Module. 
Mutual exclusion can be used to ensure that only 
one task has access to a shared resource at a time. 
Figure 8 shows how an exchange can be used to 
limit access to a resource. 
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Figure 8. Mutual Exclusion 


In this example, the X exchange is sent a single 
message at system initialization. Then, as tasks ‘re- 
quire the resource, they wait for a message from 
the X exchange. When the message is received, 
the task knows it has sole access to the resource 
because there is only one message associated 
with the exchange. After the task finishes with 
the resource it sends the message back to the X 
exchange. The next task waiting for the resource 
continues, knowing it has exclusive access to ‘the 
resource. 


EXTENSIONS. 


RMX/80 has several extensions which provide 
operations commonly used in real-time applica- 


tions. The nucleus of RMX/80 requires less than 


two thousand bytes of memory and includes all 
of the basic operations. The extensions include a 
Free Space Manager, Terminal Handler, Disk File 
System, and a ere | 


FREE SPACE MANAGER 


The Free Space Manager maintains a pool of free 
RAM and allocates memory from that pool upon 
request from a task. The Free Space Manager also 
reclaims memory and returns it to the pool when 
it is no longer needed. i : 


The Free Space Manager is seceeuily useful in $96 
applications. The first application arises: from the 
need for variable length messages. If you have a 
task that produces: messages of variable length, 
such as a task sending text for display on a:CRT, 
the Free Space Manager can be used to provide 
a message to meet your exact size requirements. 
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An alternate solution is: to maintain ‘a pool 
of. large fixed length messages. The pool can be 
maintained without the Free Space Manager; 
however, memory is wasted because of the unused 
space remaining in the fixed length messages. 


The second application of the Free Space Manager 
relates specifically to effective use of memory. 
In a typical application, the total RAM require- 
ment is computed by adding up the maximum 
RAM. requirements for each task in a system as 
shown in Figure 9...» a 


RAMTOTAL = MAXA + MAXg + MAXc 


Figure 9. RAM Requirements 


The efficiency of memory utilization is a function 
of the total RAM memory needed during typical 
system operation. Reducing the total amount of 
RAM by sharing it among the’ ‘tasks often has 
little impact on total performance. However, signi- 
ficant cost advantages may be gained by reducing 
the total amount of memory. The memory require- 
ments can be calculated as the minimum RAM for 
each task plus the pool cated memory); as shown 
in nent 10." 


POOL 


RAMTOTAL =MINA+MINB+MINC+POOL  _ 
Figure 10. RAM Requirements Usinga Pool = 
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TERMINAL HANDLER 


The Terminal Handler provides real-time asyn- 
chronous I/O between an operator terminal and 
tasks running under the RMX/80 executive. The 
Terminal: Handler provides.a line-edit capability 
similar to that of ISIS-II and an additional type- 
ahead feature. (ISIS-II is the diskette supervisor 
system used on the Intellec Microcomputer Devel- 
opment System.) Access to the Terminal Handler 
is provided by two exchanges where messages are 
sent to initiate read and write requests. 


Several features of the Terminal Handler have 
been incorporated specifically, to facilitate interac- 
tion with the debugger. Because of this-interaction, 
the Terminal Handler is required for, operation a 
the debugger. Bin, 2ee 


DISK FILE SYSTEM 


The Disk File System (DFS) provides users of 
RMX/80 with disk file management capabilities. 
This system allows user tasks to.create, access, and 
maintain disk files in a real-time environment. This 
means that many I/O requests can be processed 
concurrently, rather than one at a time: 


In addition to the file handling services, DFS pro- 
vides a program loading facility that allows you to 
load program segments into memory from disk. 


The DFS can be configured to include only those 
functions which you require. For example, if 
your disk accesses are sequential rather than 
random, you omit the SEEK function. This philo- 
sophy of minimizing memory requirements by 
including only the functions your application. re- 
quires is found in virtually all aspects of RMX/ 80. 


DEBUGGER 


An environment that | is continually changing in 
response to asynchronous physical events can pre- 
sent a serious debugging challenge. The Debugger 
aids you in debugging tasks running under the 
RMX/80 executive. The Debugger provides a 
command language that can be used to passively 
display information about the system, or See 
modify and interact a the Sys, 


Passive Panctions ae o 


Because RMX/80 manages a fairly complex set of 
data structures, the Debugger has the capability 
of displaying them in an intelligible format. The 
Debugger can. be used. in this manner. to. view 
tasks,. exchanges, messages, and other data struc- 
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tures maintained within the RMX/80 environment. 
The contents of all RAM and ROM memory loca- 
tions may also be displayed by the Debugger. 


Active Functions 


The active Debugger functions include those a 
modifying memory, setting breakpoints, and moni- 
toring stack overflow. The memory modification 
commands enable you to update the contents of 
memory and to move a series of bytes from any 
location to any other location. 


Breakpoints can be set, allowing you to gain con- 
trol when encountered by a task. Two kinds of 
breakpoints are supported: execution breakpoints 
and exchange breakpoints. An execution break- 
point can be placed at any instruction within read/ 
write (RAM) memory. When the breakpoint is 
reached, the task encountering the breakpoint is 
stopped from further execution. The task registers 
may then be examined and modified before resum- 
ing execution. 


Bechane Breakpoits can be used to detect 
RQSEND and/or RQWAIT operations performed 
on specified exchanges. The exchange breakpoint 
can thus enable you to monitor the activity of any 
of the exchanges in your system. The task execut- 
ing the appropriate RQSEND or RQWAIT to an 
exchange which has a breakpoint is stopped, allow- 
ing you to examine the task. This enables you to 
breakpoint a ROM resident task. The breakpointed 
task and the message involved in the operation 
with the exchange may then be displayed and 
modified before resuming execution. 


The debugger can also be used to monitor stack 
overflow. This function is provided by the De- 
bugger SCAN command which examines the stacks 
of all tasks in the system at a specified periodic 
interval. The fact that each task’s stack is initialized 
with a unique value allows. stack overflow to be 
detected. When a task stack overflows, it. is re- 
moved from the system and a message is displayed. 


USING RMX/80 | | 

This section of the application note describes the 
steps’ involved in using RMX/80. The process 
begins with the definition of the individual tasks 
and: exchanges in your application. It continues 
with a discussion of the data structures that you 
must prepare. The task coding, compilation or 
assembly, linking, and locating is also described. 
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Finally, some comments are directed towards de- 


bugging tasks within the: RMX/80 envirnment. | 


Before the details of using RMX/80 are discussed, 
some general observations are necessary to deter- 
mine the suitability of RMX/80 for your applica- 
tion. To effectively utilize RMX/80, your applica- 
tion must either use interrupts or require device 
polling. Thus, the key element is the need to 
respond to external events. If your application 
satisfies this criteria, it is a likely candidate. How- 
ever, you must then determine if RMX/80 is capa- 
ble of supporting your application. This can be 
done by examining your interrupt response time 
and frequency tequirements. The time required to 
transform an interrupt into a message that is sent 
to an interrupt exchange is approximately 800 
microseconds for an SBC 80/20. This is the 
RMX/80 interrupt latency. It can be reduced to 
60 microseconds by handling the interrupt directly, 
using the RQSETV operation to bypass the 
RMX/80 interrupt exchange mechanism. In this 
latter mode, an interrupt-driven asynchronous 
block transfer rate of about 10 kHz can be achieved. 


TASK AND EXCHANGE DEFINITION 


The initial design step for an application that runs 
under the RMX/80 Executive is to define your 
tasks, exchanges, and the interaction between 
them. This is perhaps best accomplished using the 
graphic notation introduced earlier in the section 
on Send — Wait Interaction. The graphic notation 
provides a clear picture of the relationships be- 
tween the tasks and: exchanges in your system. 
You can begin either in a top-down or bottom-up 
fashion. That is, you can use a top-down approach 
to define, at a gross level the operation of your 


system and then gradually’ break it down to the 
individual tasks. Or, you can start with the tasks | 


associated with the external events in your appli- 
cation and then build the pieces to form the. gross 
structure of your system. 


The bottom-up approach forces you to begin with 
external events that drive your system. The num- 
ber of these events, the amount of processing 
required, and the relationships between them 
define the tasks and exchanges in a system. For 
example, consider a system that samples an analog 
input with an A/D converter. Assume that the A/D 
provides an interrupt at the completion of a con- 
version. To use the data from the A/D converter it 
may also be necessary to scale it and add an offset. 


With this information the portion of the task and 
exchange definition ‘that relates to this function 
can be constructed. | 


Begin with. the external event: ihe interrupt from 
the A/D. An ‘interrupt priority level must be as- 
signed to the A/D converter. This same level. will 
be used by the task Which waits on the ae 
exchange. , 


The relationship Benveen the interrupt exchange 
and the A/D task is shown in Figure 11. If pro- 
cessing must be performed on raw data from the 
A/D, a second, lower priority, task could be used. 
Another task for this function will require a syn- 
chronizing signal from the ADC task to indicate 
that raw A/D data has been obtained ang is ready 
for processing. 


Figure 11. Interrupt Exchange and A/D Task 


The interaction between the ADC task and the 
CONV task that processes the raw A/D data is 
shown in Figure 12. Two exchanges provide 
synchronization. The ADC task uses the TRGR 
exchange to signal that data is ready for process- 
ing by the CONV task. The CONV task uses the 
RTRGR exchange to signal the completion of its 
processing and thus its readiness to accept more 
raw data. | 


- Figure 12.. ADC and CONV Task Interaction | 
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In this example two tasks and three exchanges 
have been defined. To develop an entire system, 
the tasks and exchanges associated with all of the 
external events in the system can be defined in 
the same manner. Then, proceeding bottom-up, 
the next step is to define the tasks and exchanges 
required to support the interaction between tasks 
running at the level of the real-time events. 


After defining. the entire application, you can begin 
actual coding of the tasks. You may choose to 
code in either assembly language or the PL/M 80 
high-level language. Where possible, it is desirable 
to code in PL/M because PL/M lends itself to 
structured programming. Assembly language often 
encourages an ad hoc approach. Even if your appli- 
cation ultimately requires assembly language coding 
because of critical time and/or space parameters, 
initial design work in PL/M followed by transla- 
tion into assembly language is recommended. 


A total of 15 operations are supported by the 
RMX/80 nucleus. Only two of the operations, 
RQSEND and RQOWAIT, are described in any detail 
in this application note. The remaining operations 
are described in the RMX/80 User’s Guide. The 
reason for presenting only the send and wait opera- 
tions is because they are sufficient for the imple- 
mentation of a large number of real-time applica- 
tions. These two operations provide a great deal of 
power and flexibility, yet their simplicity should 
enable those who are new to real-time program- 
ming to quickly develop applications. 


PRIORITY ASSIGNMENT 


The relative priority of tasks within a system run- 
ning under RMX/80 determines which task is to 
be executed. Therefore, the assignment of a pri- 
ority to each task is extremely crucial. For exam- 
ple, consider a compute bound task placed at a 
higher priority than an interrupt-driven task 
responsible for servicing an I/O device. This im- 
proper assignment of priorities could result in 
missed interrupts from the I/O device. Several 
steps can be followed in the assignment of task 
priorities. 


1. Assign hardware: interrupt priority levels 
according to the requirements of your appli- 
cation. 


2. Specify priorities for the tasks which service 
the interrupts. These tasks should generally 
be short and serve only to perform the data 
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transfers. A second task with a priority lower 
than those assigned to the hardware inter- 
rupts should be used where further processing 
of the data is required. | 


3. Priority assignment should be made for all 
other tasks in the system based on the relative 
importance and interaction among the tasks. 


Unfortunately the last step in assigning task pri- 
orities is largely intuitive. In fact, you may need 
some empirical data from actually running your 
application before you settle on your final task 
priority assignment. 


STATIC DESCRIPTORS 


When a system running under RMX/80 begins 
execution, several tables of data are used to ini- 
tialize the system. These tables usually reside in 
ROM. The first table is the create table (RQCRTB) 
that specifies the number of tasks and exchanges 
in the system, and the addresses of the initial 
task table and the initial exchange table. The ini- 
tial exchange table contains the addresses of all 
the exchange descriptors. The initial task table 
contains the static task descriptors for each task, 
and contains the following task parameters. 


1. Name | | 

2. Initial PC — the location at which to start 
task execution 

3. Initial SP — the location at which to start 
the task stack | 

4. Stack length | 

5. Priority 

6. Initial Exchange (described in the RMX/80 
User’s Guide) — 

7.TD Address — the RAM address of the task 
descriptor - 


You must prepare all three of these tables to pro- 
duce a configuration module for RMX/80. The 
release diskette for RMX/80 includes a set of files 
which contain assembly language macros that sim- 
plify the preparation of your configuration module. 
The relationship between these tables is shown in 
Figure 13. 


COMPILATION/ASSEMBLY 


Preparing program segments for compilation and 
assembly can be simplified by use of files provided 
on the RMX/80 diskette. As described in the last 
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section, a set of macros is included to assist you in 
preparing your configuration module. Other files 
are provided that are useful when coding calls to 
RMX/80 and preparing data structures in PL/M. 


RQCTAB tET 


ITT POINTER 
TASK 
COUNT 


EXCHANGE-ADDRESS-1 
EXCHANGE-ADDRESS-2 


ao w NYO © 


IET POINTER e 


EXCHANGE-ADDRESS-n . 


EXCHANGE 
COUNT 


Figure 13. ROM Based Tables 


By coding in a modular fashion you can separately 
compile and maintain tasks. This is advisable since 
a single large module containing all your tasks 
would require a lengthy recompilation to change 
any one of the tasks. Following the ok es 
and assembly of your source code modules, 
library containing the object modules can be 
created. 


LINKING 


The process of linking prepares a single object mo- 
dule from libraries containing the RMX/80 object 
modules and your own application libraries or se- 
parate object modules. The order in which you 
specify the files to be linked is crucial to successful 
linking. In general, your libraries or separate object 
modules should be specified before the RMX/80 
libraries. The link command should conclude with 
the unresolved library (UNRSLV.LIB) that con- 
tains miscellaneous modules for resolving PUBLICs 
not used in the application code. PUBLICs extend 
the scope of variables to allow linkage between 
separate program modules. Figure 14 illustrates 
how an application program is linked from RMX/80 
and user tasks. 


LOCATING 


It is appropriate in this section to give some guide- 
lines regarding the assignment of RAM and ROM 
address space for your Single Board Computer 
environment. The SBC 80 Single Board Computers 
have ROM based at location 0. Since the LOCATE 
program places all code in a contiguous block, the 
code must begin at location 0. Likewise, the read/ 
write (RAM) data is also placed in a contiguous 
block. The base address of data should be placed 
at your RAM base address. Depending on the 
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amount of code space required by your applica- 
tion it may be necessary to move the RAM mem- 
ory base address on your SBC to a higher location. 
A STACKSIZE of zero should be specified because 
you allocate stack for each RMX/80 task in the 
static task descriptors. 


DEBUGGING 


As mentioned in the overview of the RMX/80 De- 
bugger, the real-time environment is a complex 
one in which to debug your programs. Intel pro- 
vides two tools that you can use for debugging. 
The RMX/80 Debugger and the Intel In-Circuit 
Emulator (ICE). It is desirable to have both os 
these debugging tools at your disposal. 


co a 
High Speed 
“RMX/80 . Math Driver 
_ Executive jin: 


% a 
Analog 1/0 “ey, 
es lA 


User Task 


Figure 14. RMX/80 Linking 


ICE enables you to use Intel Microcomputer Devel- 
opment System memory in place of SBC 80 mem- 
ory. This allows RAM residency during your debug- 
ging as opposed to programming PROMs for each 
iteration. Your system may initially fail before the 
RMX/80 Debugger can begin operation. In this 
situation ICE can be used to debug your program. 


APPLICATIONS 


RMX/80 is suitable for a wide variety of applica- 
tions. Two specific examples are presented in this 
application note. Each example illustrates the 
steps involved in using RMX/80 and provides a 
detailed description of the coding itself. 


MINIMAL TERMINAL HANDLER 


The basic functions required for a terminal handler 


are well defined. The handler must respond to 
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operator input, transmit output characters, and 
echo characters as they are entered. This applica- 
tion note describes one implementation of a mini- 
mal terminal handler. 


The terminal handler presented here is not the 
RMX/80 Terminal Handler. It does provide some 
common functions and uses the same exchanges 
and message formats. However, many features 
of the RMX/80 Terminai Handler have been left 
out. Omitted features include special hooks to run 
with the Debugger, an alarm exchange, control S, 
Q, and O operations. 


As described in the chapter on using RMX/80, the 
process of developing an RMX/80 application be- 
gins with the definition of the tasks and exchanges. 
The graphic notation is used to prepare a diagram 
(Figure 15) showing the tasks, exchanges, and their 
interaction. 


— TASKS 


USER — TASKS 


— EXCHANGES 


USER 


— EXCHANGES 


RECEIVER 


READY 


Figure 15. Minimal Terminal Handler 


USART TRANSMITTER : 
READY 


As shown in Figure 15, the RDMIN task waits 
on the RQINPX exchange for input requests. The 
RDMIN task also successively waits on the RQL6EX 
and RQL7EX exchanges. It uses the RQL6EX 
exchange to determine when a character has been 
received by the USART. The RQL7EX exchange 
is used to indicate when the transmitter is ready 
to accept another character. RDMIN uses RQL7EX 
for echoing input characters. 


The WRMIN task waits on the RQOUTX exchange 
for output requests. When it receives a request, it 
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waits on the RQL7EX to determine when charac- 
ters can be sent to the USART. 


The following listing* shows the RDMIN and 
WRMIN tasks. These tasks provide a minimal ter- 
minal handler. The program is written in PL/M. 
The WRMIN task is also presented in assembly 
language in Appendix B. The program listing is 
interspersed with explanatory text. The program 
begins with the program segment label “‘MINI- 
MALSTERMINALSHANDLER:”’ and a DO state- 
ment. 


1 MINIMALSTERMINALSHANCLER: 


bo; 


Several macros are declared using the reserved 
word LITERALLY. These macros are expanded 
at compile time by textual substitution. 


1 DECLARE TRUE LITERALLY BEFE 
1 DECLARE FOREVER LITERALLY (WHILE TRUE' 


/* SPECIAL ASCII CHARACTERS */ 
DECLARE 

LITERALLY '@7H', 
LF LITERALLY '‘@AH', 
LITERALLY '@DH', 
LITERALLY '12H', 
LITERALLY '18H', 
LITERALLY '1BH', 
LITERALLY '7FH'; 


CONTROLSK 
CONTKOLSX 


RUBOUT 


Some macros are used to simplify the declaration 
of RMX/80 data structures. The structures de- 
clared here are for the exchange descriptor, inter- 
rupt exchange descriptor, and the messages used 
by the minimal terminal handler. 


DECLARE rile Crest alana LITERALLY ‘STRUCTURE ( 
MESSAGESHEAD ADDRESS 

MESSAGESTAIL ADDRESS, 

TASKSHEAD ADDRESS, 

TASKSTAIL ADDRESS, 

EXCHANGESLINK ADDRESS) ' 


DECLARE eke mune LITERALLY 'STRUCTURE ( 
MESSAGESHLAD ADDRES 

MESSAGESTAIL aepeese. 

TASKSHEAD ADDRESS, 

TASKSTAIL ADDRESS, 

EXCHANGESLINK ADDRESS, 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE) '; 


DECLARE THSMSG LITERALLY ‘STRUCTURE ( 
LINK ADDKESS, 

LENGTH ADDRESS, 

TYPE BYTE, 

HOMESEXCHANGE ADDRESS, 
RESPONSESEXCHANGE ADDRESS, 

STATUS ADDRESS, 

BUPFERSADDRESS ADURLSS, 

COUNT ADDRESS, 

ACTUAL ADDRESS) '; 


The following macros are specifically for the SBC 
80/20. The macros require changes to run the 
minimal terminal handler on a different Single 
Board Computer. Intel 8253 timer/counter and 
8251 USART chips are used. 


*Full size listings in Appendixes A and C. 
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8253 PORT: ADDRESSES. . < - au 2 eae LP SR 
* 


8 1 DECLARE A8253$MODE LITERALLY '@DFH'; 
9 1 DECLARE A8253$CTR2 “LITERALLY '@DEH’; 
*® 
8253 COMMANDS. 
*f ; 
10 1 DECLARE SELECT$2 LITERALLY 100000003"; 
11. 1 | DECLARE RLSBOTH LITERALLY. '00116000B"; 
12,1 DECLARE MODE$3 LITERALLY '80000110B'; 
13. 1. DECLARE B240@ LITERALLY '@@1CH'; 
= ve ; 
. 8251 PORT ADDRESSES. 
aa 
1401 DECLARE USART$IN LITERALLY 'OECH',. 
USARTSOUT LITERALLY '@ECH', 
USARTSCONTROL LITERALLY "GEDA"; 
/* ; , 
8251 MODES. 
* : : = 
15 l DECLARE STOP$1 LITERALLY '01000000B'; 
16. 1 ‘DECLARE CL8 LITERALLY '60001100B'; 
17,1 DECLARE RATE$16X LITERALLY ''00000010B'; 
/ * 
8251 COMMANDS. 
* 
eo 910000008", 


DECLARE USARTS$RESET LITERALLY 
RTS 


LITERALLY '80100000B', 
Sone wrnen LITERALLY '60618000B', 
RX LITERALLY '@8000100B', 
as LITERALLY '08060010B', 
TXEN LITERALLY '@0000001B'; 


RDMIN and WRMIN call three RMX/80 opera- 
tions. They are RQSEND, RQWAIT, and RQELVL. 
RQSEND and RQWAIT allow tasks to send and 
receive messages from exchanges. RQELVL enables 
a specific interrupt level. ) 


RYSEND: 
PROCEDURE (EXCHANGESPOINTER,MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTER, Roe ne nCre ey ADDRESS; 
END RWSEND; 


RWWAIT: 
PROCEDURE (EXCHANGESPOINTER,DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGES POINTER,DELAY) ADDRESS; 
' END RQWAIT; 


RYELVL: 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; 
END RWELVL; 


np 
w 
NPD - Nw - Nt _ 


The exchange descriptors and interrupt exchange 


descriptors must be PUBLIC because they are 
referenced by the configuration module. 


DECLARE RQINPX EXCHANGESDESCRIPTOR PUBLIC; 


28 1 

29 1 DECLARE RyOUTX EXCHANGESDESCRIPTOR PUBLIC; 

38 1 DECLARE RQL6EX INTSEXCHANGESDESCRIPTOR PUBLIC; 
31 1 


DECLARE RQL7EX INTSEXCHANGESDESCRIPTOR PUBLIC; 


The following procedure initializes the 8253 and 
8251 (USART). The 8253 generates the baud rate 
clock (2400 baud in this example). The program 
sends four nulls to the USART control port to 
ensure that the USART is ready for a command, 
no matter what state it was previously in. The pro- 
gram then sends a reset command to the USART, 
followed by the mode and another command. 


3201 INITIALIZATION: 
PROCEGURE; 
33.0 2 OUTPUT (A8253$MODE) = SELECT$2 OR RLSBOTH OR. MODES3; 
342 OUTPUT (A8253SCTR2) = LOW(B2408); 
35002 OUTPUT (A8253SCTR2) = HIGH (B24UD) ; 
362 OUTPUT (USARTSCONTROL) , 
OUTPUT (USARTSCONTROL) , 

OUTPUT (USARTSCONTROL) , 

OUTPUT (USARTSCONTROL) = 0; 
37,2 OUTPUT (USARTSCONTROL) = USARTS$RESET; 
382 OUTPUT (USARTSCONTROL) = STOP$1 OR CL8 OR RATES16X; 
392 OUTPUT (USARTSCONTRCGL) = RTS OR ERRORSRESET OR 

RXE OR DTR OR TXEN; 

40 2 END INITIALIZATION; age tS 


2-16 


Tasks coded. in PL/M take the form of parameter- 
less. PUBLIC procedures. The procedure declara- 
tion is followed by the variables used in RDMIN. 
MSGPTR receives the address of an input request 
message. The based-variable MSG accesses the 
data in the input request message. INTMSG is a 
dummy variable which simply receives the address 
of the interrupt message. BUFSADDRESS points 
to the buffer where the input characters are to be 
placed. The BUF array is based at the buffer 
pointed to by BUFSADDRESS. _ 


41 1 RDSMIN: 
PROCEDURE PUBLIC; 
42 2 DECLARE (MSGPTR,INTMSG, BUPSADDRESS) ADDRESS; 
43 2 DECLARE (CHAR,PTR,I) BYTE 
44 2 DECLARE MSG BASED MSGPTR THSMSG 
45 2 DECLARE (BUF BASED BUPSADDRESS)” (1) BYTE; 


The RDMIN task echoes characters after they are 
read in. The ECHO$CHAR procedure performs this 
function. It waits for a level 7 interrupt, indicating 
that the transmitter is ready for another character. 
ECHOS$CHAR then transmits the character. 


46 2 ECHOSCHAR: 

me PROCEDURE (CHAR); 

47,3 "DECLARE CHAR BYTE; 

48 3 INTMSG = RQWAIT(.RQL7EX,2); 
49° 3 OUTPUT (USARTS$OUT) = CHAR; 
593 END ECHOSCHAR; 


Execution of the RDMIN task starts with the next’ 
statement, a call to the initialization procedure. 
This call is followed by two calls to the procedure 
which will enable interrupt levels 6 and 7. 


51 2 CALL INITIALIZATION; 
52 2 CALL RKYUELVL (6) ; 
53 2 CALL RQELVL(7); 


The basic structure of an RMX/80 task is that of 
a program with an imbedded infinite loop. This 
loop starts with the DO FOREVER statement. 
In the continuous loop, the task waits for an input 
request message. This wait is satisfied when some 
other task in the system sends an input request 
message to the RQINPX exchange. The based 
variable used to point to BUF is assigned from a 
field in the input request message, MSG.BUF- 
FERS$ADDRESS. An index for the BUF array, 
PTR, and the variable CHAR are initialized. 


DO FOREVER; 


54 2 

55 3 ‘ MSGPTR = RQWAIT(.RQINPX,@); 

56 3 BUFSADDRESS = MSG. BUFFERSADDRESS - 1; 
57 3 PTR = 0; 

58 3 . CHAR = NOT CR; 


Task execution continues inside the next loop 
until a carriage return (CR) is input. An escape 
character (ESC) within the loop simulates a CR 
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which enables an exit from the loop. The task 
simply waits on the RQLOEX exchange for a mes- 
sage. This amounts to an interrupt service routine. 
When the wait is satisfied, the USART has received 
a character. : 


59 3 DO WHILE CHAR <> CR; 
60 4 INTMSG = RQWWAIT(.RQL6EX,8) ; 


The next statement performs a whole series of 
operations. The character input from the USART 
is logically ANDed with 7FH to mask off the parity 
bit, assigned to the variable CHAR, and tested to 
determine if it is a RUBOUT character. If a RUB- 
OUT is found, either a BELL is echoed to the ter- 
minal if there are not characters to delete in the 
buffer (PTR = 0), or the last character in the 
buffer is echoed and the pointer is decremented. 


IF (CHAR := INPUT(USARTSIN) AND 7FH) = RUBOUT THEN 
DO; 


IF PTR = ®@ THEN 
CALL ECHOSCHAR (BELL) ; 
ELSE 
DO; 
CALL ECHOSCHAR(BUF(PTR)); 
PTR = PTR - 1; 
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If CHAR is not a RUBOUT, it is tested for a 
CONTROL$X. The function of a CONTROL$X 
is to delete the entire line by resetting PTR to 
zero. After deleting the line, the system prompts 
the operator with a “‘#” character and is ready to 
accept a new line. 


IF CHAR = CONTROLS$X THEN 
DO; 


CALL ECHOSCHAR('#'); 
CALL ECHOSCHAR(CR); 
CALL ECHOSCHAR(LF) ; 
PTR = Q; 

END; 
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The next test determines if CHAR is a CON- 
TROL$R. CONTROLSR echoes the entire line 
that has been entered. This function is useful for 
displaying a line containing a number of RUBOUTs. 
Such lines can be difficult to interpret because 
RUBOUT echoes deleted characters. Because 
CONTROLSR echoes only the remaining data 
in the buffer, it eliminates “garbage” from the 
display. 


ELSE 
DO; 


IF CHAR = CONTROLSK THEN 
DO; . 


CALL ECHOSCHAR (Ck); 
CALL ECHOSCHAR (LF); 


ta 
CALL ECHOSCHAK(BUF (I)); 
END; 
END; 
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The character is then placed in the buffer unless 
the end of the buffer has been reached. If the 
buffer is full, a BELL is sent to the terminal. 


IF PTK < MSG.COUNT THEN 
BUF (PTR := PTK+1) = CHAR; 
ELSE 


0; 
IF ChAR <> Ck THEN 


CHAR = BELL; 
LND; 
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The last test is tor an ESC character. It is echoed as 
a ““$” and is treated as if a CR were entered. 


IF CHAK = ESC THEN 


GO; 
CALL ECHOSCHAR('S$'); 
CHAK = CR; 


END; 
CALL ECHOSCHAR (CHAK) ; 
D; 
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The program places a line feed (LF) at the end of 
the buffer when an exit is forced by a CR or an 
ESC. The input request message actual character 
count (MSG.ACTUAL) and the status (MSG. 
STATUS) are set before sending the message to 
its response exchange. 


IF PTR < MSG.COUNT THEN 
BUF (PTR:=PTR+1) = LF; 
MSG.ACTUAL = PTR; 
MSG.STATUS = 6; ; 
CALL RYSEND (MSG. RESPONSESEXCHANGE,MSGPTR) ; 
CALL ECHUSCHAR(LF) ; 
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END KCSMIN; 


The WRMIN task begins by enabling interrupt 
level 7. Note that no other initialization is per- 
formed before WRMIN waits for an output request 
message to arrive at the ROOUTX exchange. Here 
correct operation depends on the fact that RDMIN 
has a higher priority than WRMIN. Were this not 
the case, WRMIN could try to transmit a message 
before the 8253 and 8251 have been set up. 


WRSMIN: 
PROCEDURE PUBLIC; 
DECLARE (MSGPTR,INTMSG,BUFSADDRESS) ADDRESS; 
DECLARE PTR BYTE; P 
DECLARE MSG BASED MSGPTR THS$MSG; 
DECLARE (BUF BASED BUFSADDRESS) (1) BYTE; 


CALL RYELVL (7); 
DO FOREVER; 


MSGPTR = RQWAIT(.RQOUTX,®) ; 
BUFSADDRESS = MSG.BUFFERSADDRESS - 1; 
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The next loop transmits all of the characters speci- 
fied by the output request message. Once again, 
the interrupt service routine is implemented by 
simply waiting on the RQL7EX exchange for a 
transmitter ready interrupt message. When this 
message is received, the next character in the 
buffer is transmitted. 
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DO PTR = 1 TO MSG.COUN 
INTMSG = RQWAIT(. ROUTER: O)3 


OUTPUT (USARTSOUT) = BUF (PTR); 
ND; 
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The WRMIN task concludes by setting the actual 
count and status, and then sends the output re- 
quest message to its response exchange. 


MSG.ACTUAL = MSG.COUNT; 
MSG.STATUS = 0; 
CALL RQSEND (MSG. RESPONSESEXCHANGE,MSGPTR) ; 
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END; 
END WRSMIN; 


Using the macros provided on the RMX/80 dis- 
kette, the following static task descriptors (STD) 
should be placed in your configuration module. 


STD 
STD 


RDMIN,64,112,0 
WRMIN,64,128,0 


The entries in the STD are interpreted as follows. 


STD -NAME,STKLEN,PRI,EXCH 

where: 

NAME = the symbolic name assigned to the task asso- 
ciated with the STD 

STKLEN = the number of bytes allocated to the task 
stack 

PRI = the task priority level 

EXCH = an optional field, usually 0 


Priorities of 112 and 128 have been assigned to 
RDMIN and WRMIN because they correspond to 
hardware interrupt levels 6 and 7. 


The following exchange addresses should be 
placed in your configuration module. 


XCHADR 


ROINPX 
XCHADR RQOUTX 
XCHADR ROL6GEX 
XCHADR ROL7EX 


The XCHADR macro only requires the address of 
the exchange descriptor. 


Characters typed at the terminal are ignored unless 
an input request message has been received. Thus, 
type-ahead is not a built-in feature. However, 
if type-ahead is desired, it is sufficient to ensure 
that input requests are always queued for the 
RDMIN task and that the full input buffers are 
sent to an exchange that queues full buffers. 
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This can easily be accomplished by sending several 
input requests to the RQINPX. These input 
requests have the address. of a “full-buffer’ ex- 
change as the response exchange and the RQINPX 
exchange as the home exchange. Then, tasks need- 
ing terminal input wait on the “full-buffer” ex- 
change and send the message to the home exchange 
when finished. 


CLOSED-LOOP ANALOG CONTROL 


In the next example, a closed-loop analog control 
subsystem using the Intel SBC 711 analog-to- 
digital board illustrates task scheduling and syn- 
chronization in a process control application. In 
general, the subsystem samples an analog input at 
specified intervals, converts the data to temperature 
in degrees centigrade, and then — based upon pro- 
grammed temperature limits — controls a heating 


element. The algorithm used provides a 2-position 


controller with neutral intermediate zone (or sim- 
ply “‘bang-bang”’ control). The control algorithm 
is shown in Figure 16. 


OUTPUT SWITCHING POINTS 


. POSITION 1 
(ON) 


or 


>) 
= 
- TEMPERATURE 


SETPOINT 


POSITION 2 
(OFF) 


Figure 16. 2-Position Controller with Neutral Intermediate 


Zone 


The graphic notation in Figure 17 diagrams the 
tasks, exchanges, and their interaction. 


RET$PULSE 
EXCH RETSTRIG 
EXCH 
GO$PULSE 
EXCH 


Figure 17. Analog Subsystem 


TSPARAMS$ 
“LOCK 


EXCH | 


CONTROL 
TASK _ 


TICKER 
TASK 
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This application includes three tasks and six asso- 
ciated exchanges. The TICKER task schedules 
the ADC task. TICKER has a very high priority 
because nothing else in the system should inter- 
fere with its scheduling activities. It is also a very 
short task since it repetitively executes a timed 
wait and then handshakes a message. 


TICKER schedules the ADC task. The ADC task 
services the A/D converter. After obtaining data 
from the A/D it handshakes with the CONTROL 
task to signal that data is ready for processing. 
The ADC task is assigned a priority equivalent 
to the level of the hardware interrupt from the 
A/D. Clearly, calculations should not be performed 
at that priority. 


Thus, CONTROL performs the processing function 
at a lower priority. The CONTROL task used the 
TS$PARAM$LOCK exchange to govern access to 
the control parameters. This avoids problems re- 
sulting when some other task is updating the pa- 
rameters at the same time the CONTROL task is 
using them for testing: 


As in the minimal terminal handler, the following 
listing contains the complete analog subsystem 
tasks and is interspersed with explanatory text. 
The program begins with the program segment 
label “ATOD:” and a DO statement. 


1 ATOD: 


The macros and externals used in this module 
are brought in by means of INCLUDEs from the 
RMX/80 diskette. 


$INCLUDE( :F1:COMMON.ELT) 

DECLARE TRUE LITERALLY ‘OFFH'; 
DECLARE FALSE.LITERALLY 'OOH'; 
DECLARE BOOLEAN LITERALLY 'BYTE'; 
DECLARE FOREVER LITERALLY ‘WHILE 1'; 
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$INCLUDE(:F1:EXCH.ELT) 
DECLARE EXCHANGE$DESCRIPTOR LITERALLY ‘STRUCTURE ( 
MESSAGE$HEAD ADDRESS, 

MESSAGE$TAIL ADDRESS, 

TASK$HEAD ADDRESS, 

TASK$TAIL ADDRESS, 

EXCHANGE$LINK ADDRESS)‘; 


$INCLUDE(:F1:IED.ELT) 
DECLARE INT$EXCHANGE$DESCRIPTOR LITERALLY 
MESSAGE$HEAD ADDRESS, 

MESSAGE$TAIL ADDRESS, 

TASK$HEAD ADDRESS, 

TASK$TAIL ADDRESS, 

EXCHANGE$LINK ADDRESS, 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE)'; 


‘STRUCTURE ( 


$INCLUDE( :F1:MSG.ELT) 
DECLARE MSG$HDR LITERALLY ¢ 
LINK ADDRESS, 
LENGTH ADDRESS, 
' TYPE BYTE, 
HOME$EXCHANGE ADDRESS, 
RESPONSE$EXCHANGE ADDRESS'; 


DECLARE MSG$DESCRIPTOR LITERALLY ‘'STRUCTURE( 
MSG$HDR, : 
REMAINDER(1) BYTE)'; 
$INCLUDE( :F1:INTRPT.EXT) 
RQENDI: 
PROCEDURE EXTERNAL; 
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102) END RQENDI; 
12 1 =  RQELVL: 

= PROCEDURE (LEVEL) EXTERNAL; 
13.2 8 DECLARE LEVEL BYTE; 
HW o2 END RQELVL; 
15 1 =  RQDLVL: 

7 PROCEDURE (LEVEL) EXTERNAL; 
16 2 = DECLARE LEVEL BYTE; 
17 2 END RQDLVL; 
18 1 =  RQSETV: 

= PROCEDURE (PROC,LEVEL) EXTERNAL; 
19 2 = DECLARE PROC ADDRESS; 
202 = DECLARE LEVEL BYTE; 
Ot. <2. aS END RQSETV; 

$INCLUDE( :F1:SY¥NCH.EXT) 

22 1 =  RQSEND: 

= PROCEDURE (EXCHANGESPOINTER,MESSAGE$POINTER) EXTERNAL; 
232 DECLARE (EXCHANGE$POINTER,MESSAGE$POINTER) ADDRESS; 
242 = END RQSEND; 
25. 1 =  RQWAIT: 

= PROCEDURE (EXCHANGE$POINTER,DELAY) ADDRESS EXTERNAL; 
26 2 = DECLARE (EXCHANGE$POINTER,DELAY) ADDRESS; 
272 END RQWAIT; 
281 RQACPT: 

= PROCEDURE (EXCHANGE$POINTER) ADDRESS EXTERNAL; 
29,2 DECLARE EXCHANGE$POINTER ADDRESS; 
302 = END RQACPT; 
31 1 =  RQISND: 

= PROCEDURE (IED$PTR) EXTERNAL; 
32022 « DECLARE IED$PTR ADDRESS; 
3300«2 Ss END RQISND; 


Additional macros are declared to aid in the use 


of the SBC 711 analog-to-digital board. 


/* 
SBC 711 ANALOG TO DIGITAL BOARD 

#/ : 
34 1 DECLARE ADC$BASE ADDRESS AT (OF700H); 
35 1 DECLARE COMMAND$REGISTER BYTE AT (.ADC$BASE+0); 
36 1 DECLARE STATUS$REGISTER BYTE AT (.ADC$BASE+0) ; 
37 1 DECLARE FIRST$CHANNEL$REGISTER BYTE AT (.ADC$BASE+1); 
38 1 DECLARE LAST$CHANNEL$REGISTER BYTE AT (.ADC$BASE+2); 
39 1 DECLARE CLEAR$INTERRUPT$REQUEST BYTE AT (.ADC$BASE+3) 3 
40 1 DECLARE ADC$DATA$REGISTER ADDRESS AT (.ADC$BASE+4) ; 
yy 1 DECLARE GO$BIT LITERALLY '1'; 
42 1 DECLARE AUTO$INCREMENT$ENABLE LITERALLY ‘2°; 
43 1 DECLARE BUSY LITERALLY '8'; 
4y 1 DECLARE EOS$INTERRUPT$ENABLE LITERALLY '10H'; 
45 1 DECLARE EOC$INTERRUPT$ENABLE LITERALLY '20H'; 
46 1 DECLARE END$OF$SCAN LITERALLY ‘4OH'; 
47 1 


DECLARE END$OF$CONVERSION LITERALLY '80H'; 


The exchange descriptors and the interrupt ex- 
change descriptors are declared. 


48 4 DECLARE DUMMY EXCHANGE$DESCRIPTCR PUBLIC; 

4g 1 DECLARE RET$PULSE EXCHANGE$DESCRIPTOR PUBLIC; 
50 1 DECLARE GO$PULSE EXCHANGE$DESCRIPTOR PUBLIC; 
51 1 DECLARE TRIGGER EXCHANGE$DESCRIPTOR PUBLIC; 
52 1 DECLARE RET$TRIG EXCHANGE$DESCRIPTOR PUBLIC; 
53 1 DECLARE RQL2EX INT$EXCHANGE$DESCRIPTOR; 


The CONTROL task uses an external data struc- 
ture to obtain operating parameters. This data 
structure (BOX$PARAMS) has an exchange asso- 


ciated with it (TSPARAMS$LOCK) that is used to 
provide mutual exclusion, ensuring that only one 
task accesses the data structure at a time. 


DECLARE T$PARAM$LOCK EXCHANGE$DESCRIPTOR EXTERNAL; 


DECLARE BOX$PARAMS(5) STRUCTURE( 
HANNEL BYTE, 
SET$POINT ADDRESS, 
ERROR ADDRESS, 
OFFSET ADDRESS, 
SAMPLES ADDRESS, 
COUNT ADDRESS, 
ACCUM ADDRESS, 
READING ADDRESS ) EXTERNAL; 
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TICKER, the scheduler task, has an initialization 
sequence in which it sets up two messages and 
sends them to the RET$PULSE exchange. Then it 
enters an infinite loop where it waits on the 
DUMMY exchange for 250 milliseconds. After 
the timed wait is complete, TICKER passes a mes- 
sage from the RET$PULSE exchange to the GO$- 
PULSE exchange. In effect this is a handshake, 
checking to see that the ADC task has completed 
its last operation and then signaling it to perform 
another. 


56 1 TICKER$TASK: 
PROCEDURE PUBLIC; 
57 2 DECLARE MSG ADDRESS; 
58 2 DECLARE PULSE$MSG(2) STRUCTURE ( 
MSG$HDR ); 
59 2 PULSE$MSG(0). LENGTH, 
PULSE$MSG(1).LENGTH = SIZE( PULSE$MSG(0)); 
60 2 PULSE$MSG(0).TYPE, 
PULSE$MSG(1).TYPE = 65; 
61 2 CALL RQSEND(.RET$PULSE,.PULSE$MSG(0)); 
62 2 CALL RQSEND(.RET$PULSE,.PULSE$MSG(1))3 
63 2 DO FOREVER; 
64 3 MSG = RQWAIT(.DUMMY,5); 
65 3 MSG = RQWAIT(.RET$PULSE,0); 
66 3 CALL RQSEND(.GO$PULSE,MSG); 
67 3 END; 
68 2 END TICKER$TASK; 


Scheduled by TICKER, the ADC task performs the 
A/D sampling. It begins by setting up TRIGGER$S- 
MSG and enabling the level 2 interrupt from the 
A/D. Inside the ADC task continuous loop, mes- 
sages are passed from the GO$PULSE exchange to 
the RET$PULSE exchange. Then it waits for ac- 
cess to the BOX$PARAMS data structure. When 
the ADC task has access, it loops through the A/D 
channels, accumulating readings in BOX$PARAMS. 
After all the A/D channels are sampled and the 
BOX$PARAMS readings updated, the LOCK$MSG 
is returned to the T$PARAM$LOCK exchange. 
The ADC task concludes the continuous loop by 
handshaking a message with the CONTROL task. 


+ ROL(GAIN,6); 


69 1 ADCS$TASK: 
PROCEDURE PUBLIC; 
70 2 DECLARE TRIGGER$MSG STRUCTURE ( 
MSG$HDR ); 
171 2 DECLARE (T$MSG,MSG,LOCK$MSG) ADDRESS; 
72 2 DECLARE I BYTE; ; 
73 2 DECLARE GAIN LITERALLY '00' 
> 7h 20% DECLARE N$CHNLS LITERALLY Bey 
75 2 TRIGGER$MSG LENGTH = SIZE(TRIGGERS$MSG)% 
76 2 TRIGGER$MSG.TYPE = 65; 
TT 2 CALL RQSEND(.RET$TRIG,.TRIGGER$MSG) ; 
78 2 CALL RQELVL(2) $ 
19 2 DO FOREVER; 
80 3 MSG = ROWAIT(. GO$PULSE,0); 
81 3 CALL RQSEND(.RET$PULSE, MSG) 
82 3 LOCK$MSG = RQWAIT(. T$PARAM$LOCK, 0); 
83 3 DO I = 0 TO N$CHNLS-1; ; 
84 4 FIRST$CHANNEL$ REGISTER = BOX$PARAMS(I).CHANNEL 
4 


COMMAND$REGISTER = GO$BIT 


OR EOCSINTERRUPT$ENABLE; 


86 4 MSG = RQWAIT( .RQL2EX,0).5° 

874 COMMAND$REGISTER = 0; 

88 4 BOX$PARAMS(I).ACCUM = BOX$PARAMS(I). ACCUM 
/ + ADC$DATA$REGISTER; 

894 END; 

90 3 CALL RQSEND(.T$PARAM$LOCK, LOCK$MSG) ; 

91 3 T$MSG = RQWAIT(.RET$TRIG,O); 

92 3 CALL RQSEND(.TRIGGER,T$MSG) ; 

93 3 END; 

94 2 END ADC$TASK; 
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The CONTROL task waits for a message from the 


ADC task signaling that A/D readings have been 


taken and are ready for further. processing. It com- 
pletes the. handshake by sending the message to 
the RET$TRIG:exchange.. Then, as in the ADC 
task, accesses the BOXSPARAMS data structure. 


Inside the next loop, the readings are averaged, 
scaled, offset, and tested. Appropriate action is 
taken to turn the heating elements on or off. The 
loop concludes by returning | the message to the 
TSPARAMSLOCK exc)aner: : 


CONTROLS TASK: 
PROCEDURE PUBLIC; 


96 2 DECLARE (LOCK$MSG,T,MSG) ADDRESS; 
97 2 ’ DECLARE I BYTE; 
98 2 DECLARE NCHNLS LITBRALLY '5'; 
99 2 DECLARE TURN$LAMP$ON 
LITERALLY 'OUTPUT(OE7H)=SHL(1,1)'; 
100 2 DECLARE TURN$LAMP$OFF 
LITERALLY 'OUTPUT(OE7H)=SHL(I,1)41'; 
1012 DECLARE SETUP$8255 LITERALLY ‘OUTPUT(0E7H)=80H; 
OUTPUT( OE6H)=OFFH'; 
102 2 SETUP$8255; : 
104 DO FOREVER; 
105 MSG = RQWAIT(.TRIGGER,O); 


CALL RQSEND(.RET$TRIG,MSG) ; 
LOCK$MSG= RQWAIT(.T$PARAM$LOCK,0); 
DO I = 0 TO NCHNLS-1; 
BOX$PARAMS(I). COUNT = BOAS PARAMS OT) COUNT + 1; 
IF BOX$PARAMS(I).COUNT 
= BOX$PARAMS(1).SAMPLES THEN 
DO; : 
tT; ; 
‘BOX$PARAMS( 1). READING 
= (BOX$PARAMS(1).ACCUM 
/BOX$PARAMS(1I).SAMPLES) / 38 
+ BOX$PARAMS(1).OFFSET; © 
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113005 IF T <= BOX$PARAMS(I).SET$POINT 
~ BOX$PARAMS(I).ERROR THEN 
11H 5 TURNSLAMP$ON; 
ELSE 
115. 5 IF T >= BOX$PARAMS(1) «SET$POINT 
__. + BOX$PARAMS( 1) ERROR THEN 
116 5 TURNSLAMP$OFF; 
BOX$PARAMS(I).ACCUM, 
a BOX$PARAMS(I) .COUNT .= 0; 
1185 END; 
119,04 END; 
120 3 _ cal RQSEND(. T$PARAM$LOCK, LOCK$MSG) ; 
121 3 EN 
122 2 END CONTROL$TASK; 
123,011 END ATOD; 


The purpose of this application note is to intro- 
duce you to the Intel RMX/80, Real-Time Multi- 
tasking Executive. The general framework of 
RMX/80 was discussed, including the nucleus and 
extensions. 


This application note described the steps involved 
in using RMX/80. Key emphasis has been placed 
on the need to fully define the tasks and exchanges 
in your application using graphic notation. 


Applications have been presented to demonstrate 
task communication, synchronization, and mutual 
exclusion in a minimal terminal handler and an 
analog subsystem. The tasks responded to real- 
time asynchronous events such as USART and 
A/D interrupts. 


RMX/80 represents a significant step in the sophis- 
tication of microcomputer software. Its ease of 
use, flexibility, and power should enable you to 
quickly implement real-time software for your 
applications. | 
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APPENDIX A 


MINITH PL/M LISTING 


MINIMALSTERMINALSHANDLERs: 
BO; 


DECLARE TRUE LITERALLY 'OFFH'; 
DECLARE FOREVER LITERALLY ‘WHILE TRUE’; 


/* SPECIAL ASCII CHARACTERS */ 


DECLARE 
BELL LITERALLY '@7H', 
LF LITERALLY ‘@AR’, 
CR LITERALLY ‘'@DH', 
CONTROLSR LITERALLY ‘'12Hh', 
CONTKOLSX LITERALLY '18h', 
BSC LITERALLY '1BH', 
RUBOUT LITERALLY '7FA’; 


DECLARE EXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MESSAGESHEAD ADDRESS, 

MESSAGESTAIL ADDRESS, 

TASKSHEAD ADDRESS, 

TASKSTAIL ADDRESS, 

EXCHANGESLINK ADDRESS) '; 


DECLARE INTSEXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MESSAGESHEAD ADDRESS, 

MESSAGESTAIL ADDRESS, 

TASKSHEAD ADDRESS, 

TASKSTAIL ALBORESS, 

EXCHANGESLINK ADDRESS, 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE)’; 


DECLARE THSMSG LITERALLY ‘STRUCTURE ( 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, | 
HOMESEXCHANGE ADDRESS, 
RESPONSESEXCHANGE ADDRESS, 
STATUS ADDRESS, 
BUFFERSADDRESS ADDRESS, 
COUNT ADDRESS, 
ACTUAL ADDRESS)’; 
y 3 | 
8253 PORT ADDRESSES. 
* / | 
DECLARE A&253SMODE LITERALLY '@DFH'; 
DECLARE A&253SCTK2 LITERALLY 'ODEH'; 
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RO BO 


* 
8253 COMMANDS. 
ws 


DECLARE SELECT$2 LITERALLY '10000000B' 
DECLARE RKLSBOTH LITERALLY '@0110600B' 


moe 6™O6 


DECLARE MODES3 LITERALLY 'O@@0W11G6B'; 


DECLARE B24@@ LITERALLY '@@1CH'; 

/* 

8251 PORT ADDRESSES. 

*/ . 

DECLARE USARTSIN LITERALLY '@ECH', 
USARTSOUT LITERALLY '@ECh', 


USARTSCONTROL LITERALLY '@EDH'; 


/* 
8251 MODES. 
ws 


DECLARE CL8 LITERALLY '@W001106B'; 


DECLARE STOPS1 LITERALLY 'O1UUU000B'; 


l 


DECLARE RATES16X LITERALLY 'O@OUWGBH10B'; 


/* 
6251 COMMANDS. 

* | | 

DECLARE USARTSRESET LITERALLY '@1GU0080B', 
RTS LITERALLY '@W1G@W00GB', 
ERRORSRESET LITERALLY '@@W1GQ000B', 
RXE LITERALLY "@O@0GG100B', 
DTR LITERALLY '@OUOOUW1GB', 
TXEN LITERALLY '@O@O80WO1B'; 


RUSEND: 


PROCEDURE (EXCHANGESPOINTER,MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTER,MESSAGES POINTER) ADDRESS; 


END RUSEND; 


RUWAIT: 
PROCEDURE (EXCHANGES POINTER, DELAY) 
DECLARE (EXCHANGES POINTER, DELAY) 
END RUWAIT; 


ROUELVL: 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; 
END RUELVL; 


ADDRESS EXTERNAL; 


ADDRESS; 


DECLARE RKQINPX EXCHANGESDESCRIPTOR PUBLIC; 
DECLARE RyOUTX EXCHANGESDESCRIPTOR PUBLIC; 


DECLARE RQL6EX INTSEXCHANGESDESCRIPTOR PUBLIC; 
DECLARE RUL/EX INTS EXCHANGESDESCRIPTOR PUBLIC; 


INITIALIZATION: 
PROCEDURE; 
OUTPUT (A8253SMODE) 
OUTPUT (A8253SCTR2) 


LOW (B24@@) ; 
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SELECTS2 OR RLSBOTH OR MODES3; 
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RO 
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Ox: 


OUTPUT (A8253SCTR2) = HIGH(B24W6); 
OUTPUT (USARTSCONTROL) , 
OUTPUT (USARTSCONTROL) , 
CUTPUT (USARTSCONTROL) , 
OUTPUT (USARTSCONTROL) 
OUTPUT (USARTSCONTROL) 
OUTPUT (USARTSCONTROL) 
OUTPUT (USARTSCONTROL) 


0; 

USARTSRESET; 

STOPS1 OR CL8 OR RATES16X; 
RTS OR ERRORSRESET OR 

RXE OR DTR OR TXEN; 


ENG INITIALIZATION; 


RDSMIN: 


PROCEDURE PUBLIC; 


DECLARE (MSGPTR,INTMSG,BUFSADDRESS) ADDRESS; 
DECLARE (CHAR,PTR,1) BYTE; 

DECLARE MSG BASED MSGPTR THSMSG; 

DECLAKE (BUF BASED BUFSADDRESS) (1) BYTE; 


&CHOSCHAR: 
PROCEDURE (CHAR) ; 
DECLARE CHAR BYTE; 
INTMSG = RQWAIT(.«ROL7EX,Q); 
OUTPUT (USARTSOUT) = CHAR; 
END ECHOSCHAR; 


CALL INITIALIZATION; 


CALL KVELVL (6) ; 
CALL RUELVL (7); 


DO FOREVER; 
MSGPTR = RQOWAIT(.«RGINPX,6); 
BUFSADDRESS = MSG.BUFFERSADDRESS - 1; 
PTR = Q; 
CHAR = NOT Ck; 
DO WHILE CHAR <> CR; 
INTMSG = RUWAIT(.ROLOEX,@); 
IF (CHAK := INPUT(USARTSIN) AND 7FH) = RUBOUT 
DO; “9 
IF PTR = @ THEN 
CALL ECHOSCHAR(BELL) ; 
ELSE 
DO; 
CALL ECHOSCHAR (BUF (PTR) ); 
PTR = PTR - 1; 
END; 
END; 
ELSE 
DO; | | 
IF CHAR = CONTROLSX THEN 
BO; - . 
CALL ECHOSCHAR('#'); 
CALL ECHOSCHAR(CR)}; 
CALL ECHOSCHAR(LF); 
PTR = 6; = 
BEND; 
ELSE 
DOs .. 
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82 


G2 


NO Oi On Cie 


POW WWW PB Ee wWWWd 


WO O~WWUAA! 


~I ~] OY 


a 


No 


DO; 
CALL BCHOSCHAR (CR) ; 
CALL ECHOSCHAR (LF) ; 
DO I = 1 TO PTR; 
CALL a a a 
END; - 


IF PTR < MSG.COUNT THEN 
BUF (PTR := PTR+1) = CHAR; 
ELSE : | 
DO; 
IF CHAR <> CK THEN 
CHAR = BELL; 


END; 

IF CHAR = ESC THEN 

BO; | 
CALL ECHOSCHAR('S'); 
CHAR = CR; 

END; 

CALL ECHOSCHAR (CHAR) ; 

END; 
END; 
END; 
END; 


LIF PTR < MSG.COUNT THEN 
BUF (PTR:=PTR+1) = LF; 
MSG.ACTUAL = PTR; 
MSG.STATUS = @; 
CALL RUSEND (MSG. RESPONSESEXCHANGE, MSGPTR) ; 
CALL ECHOSCHAR(LF) ; 


DWWWWWWW PUD ~Y~)10 © WO x~I1~1 © © OO ~) 


END; 


END RDSMIN; 


WRSMIN: 
PROCEDURE 
DECLARE 
CECLARE 
DECLARE 
DECLARE 


PUBLIC; 


(MSGPTR, INTMSG, BUFSADDRESS) ADDRESS; 
PTR BYTE; © 

MSG BASED MSGPTR THSMSG; 

(BUF BASED BUFSADDRESS) (1) BYTE; 


CALL ROEIVEAN 


DO FOREVER; 
MSGPTR = RQWAIT(.« RQOUTX, QO); 
BUFSADDRESS = MSG.BUFFERSADDRESS - 1; 


DO PTR 
INTMS 
OUTPUT (USARTSOUT; = BUF (PTR); 


END; 


= 1 TO MSG.COUNT;: .. 
RQWAIT («RQL7EX,@) ; 


MSG.ACTUAL = MSG. COUNT; 
MSG.«STATUS = @; 
CALL RQGSEND (MSG. RESPONSES EXCHANGE, MSGPTR) ; 


BEND; 


END WRSMIN; 
END MINIMALSTERMINALSHANDLER; 
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LOC 


OOBRC 


0000 
0002 


0005 
0008 
OOOB 
OOOE 
OOOF 
0012 
0013 
0014 
0015 
0016 
0017 
0018 
OO1A 
OO1B 
001D 
OOTE 
OO1F 
0020 
0021 
0022 
0023 
0024 
0025 
0026 
0027 
0028 


0029 
002A 
002B 
002K 
002F 
0030 
0033 
0036 
0039 
003A 
003B 
003C 
003D 
003F 
OO40 


OBJ 


O07 
CDOO000 


110000 
010000 
CDO000 
E5 
110700 
19 

4E 

rea 

46 

23 

C5 
3600 
es 
3600 
a3 

5E 

23 

56 

a3 

4E 


Bt 
CA4300 
C5 
D5 
110000 
0710000 
CDO000 
D1 


C32900 


APPENDIX B 


WRMIN ASSEMBLY LANGUAGE LISTING 


SEQ 


WOON NO FPwWwhd — 


DATOUT 


WRMIN: 


WRO: 


WR: 


NAME 
EXTRN 
PUBLIC 
EQU 
CSEG 


MVI 
CALL 


LXI 
LX I 
CALL 
PUSH 
LXI 
DAD 
MOV 
INX 
MOV 
INX 
PUSH 
MVI 
INX 
MVI 
INX 
MOV 
INX 
MOV 
INX 
MOV 
INX 
MOV 
INX 
MOV 
INX 
MOV 


MOV 
ORA 
JZ 
PUSH 
PUSH 
LX I 
LX I 
CALL 
POP 
POP 
LDAX 
INX 
OUT 
DCX 
JMP 
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SOURCE STATEMENT 


WRMIN 
RQELVL, RQOUTX, RQWAIT, RQSEND 
WRMIN, RQL7EX 


OECH ; USART OUTPUT PORT ADR 
Cat 

RQELVL ; ENABLE INTERRUPT LVL 7 
D,O 

B,RQOUTX 

RQWAIT s WAIT FOR OUTPUT RQST 
H ; PUSH MESSAGE ADDRESS 
D,7 

D 

C...M >; GET RESPONSE EXCHANGE 
H 

B,M 

H 

B ; PUSH RESPONSE EXCHANGE 
M,0 : “SLALUS =. 0 

H 

M,O0 

H 

EM ; GET BUFFER ADR IN DE 
H 

DM 

H 

C,M ; GET COUNT IN BC 

H 

B,M 

H 

M,C * ACTUAL = COUNT 

H 

M,B 

A,B 

C 

WRe ; EXIT LOOP IF COUNT = Q 
B 

D 

D,O 

B,RQL7EX 

RQWAIT ; WAIT FOR TXRDY INTRPT 
D 

B 

D 

D 

DATOUT 3; TRANSMIT NEXT CHAR 

B 

WR 1 
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0043 
0044 
0045 


0048 


OOOF 


Ci 
D1 
CDO000 
C30500 


E 
C 


59 


e 
3 


ROQLTEX: 


POP 
POP 
CALL 
JMP 
DSEG 
DS 


END 
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B ; BC 


D . 3 DE = 
RQSEND 3; SEND 
WRO 

“15 


RESPONSE EXCHANGE 


MSG ADDRESS 
MSG TO RESP. 


EXCH 
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APPENDIX C 


ATOD PL/M LISTING 


ATOD: 
DO; 


$INCLUDE( :F1:COMMON.ELT) 
DECLARE TRUE LITERALLY 


DECLARE FALSE LITERALLY 


‘OFFH'; 
‘OOH'; 


DECLARE BOOLEAN LITERALLY ‘BYTE‘; 
DECLARE FOREVER LITERALLY ‘WHILE 1'; 


¢INCLUDE(:F1:EXCH.ELT) 


DECLARE EXCHANGE$DESCRIPTOR LITERALLY 


MESSAGE$HEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 


TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 


EXCHANGE$LINK ADDRESS)'; 


$INCLUDE(:F1:IED.ELT) 


DECLARE INTS$EXCHANGE$DESCRIPTOR LITERALLY 


MESSAGE$HEAD ADDRESS, 
MESSAGE$TAIL ADDRESS, 


TASK$HEAD ADDRESS, 
TASK$TAIL ADDRESS, 


EXCHANGE$LINK ADDRESS, 


LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE)'; 


$¢INCLUDE(:F1:MSG.ELT) 
DECLARE MSG$HDR LITERALLY ' 


LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 


HOME$EXCHANGE ADDRESS, 


RESPONSE$EXCHANGE ADDRESS! ; 


DECLARE MSG$DESCRIPTOR LITERALLY 


MSG$HDR, 


REMAINDER(1) BYTE)'; 


$INCLUDE( :F1:INTRPT.EXT) 


RQENDI: 


PROCEDURE EXTERNAL; 


END RQENDI; 


RQELVL: 


PROCEDURE (LEVEL) EXTERNAL; 


DECLARE LEVEL BYTE; 


END RQELVL; 
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12 
16 
17 
18 


19 
20 


2) 


22 
23 
24 
25 
26 
27 
28 


29 | 


30 
an 
32 
53 


ee ee ee ee ee one 


nn oe a ee ee 


Wo oH om om Mo th ok oat EE aE OT aati 


RQDLVL: 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; 


END RQDLVL; 
RQSETV: 

PROCEDURE (PROC,LEVEL) EXTERNAL; 
DECLARE PROC ADDRESS; © | 
DECLARE LEVEL BYTE; . 

END RQSETV; 


$INCLUDE(:F1: SYNCH. EXT) 


RQSEND:?: 


PROCEDURE ge ee eae MESSAGE$ POINTER) EXTERNAL; 
DECLARE (EXCHANGE$POINTER,MESSAGES$POINTER) ADDRESS; 


END RQSEND; 


RQWAIT: 
PROCEDURE (EXCHANGE$POINTER,DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGES$POINTER,DELAY) ADDRESS; 


END RQWAIT; 


RQACPT: 
PROCEDURE ( EX CHANGE$ POINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGE$ POINTER BED hS2) 


END RQACPT; 


RQISND: 
PROCEDURE (IED$PTR) EXTERNAL; 
DECLARE IED$PTR ADDRESS; 


END RQISND; 


/% 

SBC 711 ANALOG TO DIGITAL .BOARD 
#/ | 
DECLARE ADC$BASE ADDRESS AT (OF700H); | 
DECLARE COMMAND$REGISTER BYTE AT (.ADC$BASE+0); 
DECLARE STATUS$REGISTER BYTE AT (.ADC$BASE+0) ; 
DECLARE FIRST$CHANNEL$REGISTER BYTE AT (.ADC$BASE+1); 
DECLARE LAST$CHANNEL$REGISTER BYTE AT (.ADC$BASE+2); 
DECLARE CLEAR$INTERRUPT$REQUEST BYTE AT (.ADC$BASE+3); 
DECLARE ADC$DATA$REGISTER ADDRESS AT (.ADC$BASE+4) ; 


DECLARE GO$BIT LITERALLY '1';3 : 
DECLARE AUTO$SINCREMENT$ENABLE LITERALLY eae, 
DECLARE BUSY LITERALLY '8'; | 
DECLARE EOS$INTERRUPT$ENABLE LITERALLY “10H; 
DECLARE EOC$INTERRUPT$ENABLE LITERALLY '20H'; 
DECLARE END$OF$SCAN LITERALLY '4OH'; 
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DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 
DECLARE 


DECLARE 


END$OF$CONVERSION LITERALLY ‘ 80H'; 


DUMMY EXCHANGE$DESCRIPTOR PUBLIC; 


RET$PULSE EXCHANGE$DESCRIPTOR PUBLIC; 
GO$PULSE EXCHANGES$DESCRIPTOR PUBLIC; 
TRIGGER EXCHANGE$DESCRIPTOR PUBLIC; 
RET$TRIG EXCHANGE$DESCRIPTOR PUBLIC; 


RQL2ZEX INT$EXCHANGE$DESCRIPTOR; 


T$PARAM$LOCK EXCHANGE$DESCRIPTOR EXTERNAL; 


BOX$PARAMS(5) STRUCTURE( 
CHANNEL BYTE, 

SET$POINT ADDRESS, 

ERROR ADDRESS, 

OFFSET ADDRESS, 

SAMPLES ADDRESS, 

COUNT ADDRESS, 

ACCUM ADDRESS, 

READING ADDRESS ) EXTERNAL; 


TICKER$TASK: 
PROCEDURE PUBLIC; 
DECLARE MSG ADDRESS; 
DECLARE PULSE$MSG(2) STRUCTURE ( 


MSG$HDR ); 


PULSE$MSG(0).LENGTH, 


PULSE$MSG(1).LENGTH = SIZE( PULSE$MSG(0));3 


PULSE$MSG(0).TYPE, 
PULSE$MSG(1).TYPE = 65; 


CALL RQSEND(.RET$PULSE,.PULSE$MSG(0)); 
CALL RQSEND(.RET$PULSE,.PULSE$MSG(1));3 


DO FOREVER; 
MSG = RQWAIT(.DUMMY,5); 
MSG = RQWAIT(.RET$PULSE,O); 


CALL RQSEND(.GO$PULSE,MSG) ; 
END; | 


END TICKER$TASK; 


ADC$TASK: 
PROCEDURE PUBLIC; 


DECLARE 


DECLARE 
DECLARE 
DECLARE 
DECLARE 


TRIGGER$MSG STRUCTURE ( 
MSG$HDR ); 
(TS$MSG,MSG,LOCK$MSG) ADDRESS; 
I BYTE; 

GAIN LITERALLY '00'; 

N$CHNLS LITERALLY '5'; 


TRIGGER$MSG.LENGTH = SIZE(TRIGGER$MSG) ; 
TRIGGER$MSG.TYPE = 65; 

CALL RQSEND( «<RET$TRIG,.TRIGGER$MSG) ; 
CALL RQELVL(2) ; 
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DO FOREVER; 
MSG = RQWAIT(.GO$PULSE,O) ; 
CALL RQSEND( -RET$PULSE,MSG) ; 
LOCK$MSG = RQWAIT(.T$PARAM$LOCK,0) ; 
DO I = 0 TO N$CHNLS-1; 


"FIRST$CHANNEL$REGISTER = BOX$PARAMS( 1) . CHANNEL 


+ ROL(GAIN,6); 
COMMAND$REGISTER = GO$BIT 
| | OR EOC$INTERRUPT$ENABLE; 
MSG = RQWAIT(.RQL2EX,0); 
COMMAND$REGISTER = 0; 
BOX$PARAMS(I).ACCUM = BOX$PARAMS( I). ACCUM 
| + ADC$DATA$REGISTER; 
END; 
CALL RQSEND(. -T$PARAM$LOCK, LOCK$MSG) ; 
T$MSG = RQWAIT(.RET$TRIG, 0); 
CALL RQSEND(. TRIGGER, TSMSG) 5 
END; 


END ADC$TASK; 


CONTROL$TASK: 
PROCEDURE PUBLIC; 

DECLARE (LOCK$MSG, sie MSG) ADDRESS; 

DECLARE I BYTE; | 

DECLARE NCHNLS LITERALLY stu 

DECLARE TURN$LAMP$ON 
LITERALLY 'OUTPUT(OE7H)=SHL(1,1)'; 

DECLARE TURN$LAMP$OFF 
LITERALLY 'OUTPUT(OE7H)=SHL(1I,1)41'; 

DECLARE SETUP$8255 LITERALLY ‘ OUTPUT(OE7H) = 80H; 

| OUTPUT(0E6H) = OFFH' 


SETUP$8255; 


DO FOREVER; 
MSG = ROWAIT(. -TRIGGER,O); 
CALL RQSEND(. RET$TRIG, MSG); 
LOCK$MSG= RQWAIT(. -T$PARAM$LOCK,0); 
DO I = O TO NCHNLS-1; 


BOX$PARAMS(I).COUNT = BOX$PARAMS(I).COUNT + 1; 


IF BOX$PARAMS(1I).COUNT 
= BOX$PARAMS(I).SAMPLES THEN 


BOX$PARAMS(I).READING 
= (BOX$PARAMS(1I).ACCUM 
/BOX$PARAMS(I).SAMPLES) / 38 
+ BOX$PARAMS(1I).OFFSET; 
IF T <= BOX$PARAMS(1I).SET$POINT 
= So ee anys -ERROR THEN 
| TURNSLAMP$ON; 
ELSE 
IF T >= BOX$PARAMS(I). SET$POINT 
+ BOX$PARAMS(1I).ERROR THEN 
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116 5 TURN$LAMP$OFF; 
BOX$PARAMS(I). ACCUM, 
BOX$PARAMS(I).COUNT = 0; 


118 5 END: 

119 4 END; 

120 3 CALL RQSEND(.T$PARAM$LOCK,LOCK$MSG) ; 
121 3 END; 

122 2 END CONTROL$TASK; 

123. 1 END ATOD; 
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I, INTRODUCTION 


In March of 1978, Intel announced the availability of a 
resident FORTRAN compiler for the Intellec® Micro- 
computer Development System. In November of 1978, 


Intel announced the availability of a run-time package ' 


to support the execution of FORTRAN-80 compiled 
programs in the RMX/80™ environment. With this sup- 
port package, user’s of Intel’s complete line of iSBC™ 
Single Board Computer products can benefit from the 
full set of I/O and math capabilities provided by the 
FORTRAN-80 language. 


This application note is intended to familiarize the 
reader with the features, benefits and usage of the 
FORTRAN-80 package and RMX/80™ Executive. The 
reader who is unfamiliar with any of these topics is 
urged to refer to the related Intel publications listed in 
the front-piece. 


Following the overview, two application examples will 


be studied. In the first example, FORTRAN code is used . 


in a “stand-alone” environment; i.e., without operating 
system support. The second example is a multitasking 
system managed by the RMX/80 Executive which sup- 
ports standard I/O interfaces to the RMX/80 Terminal 
Handler and Disk File System. | 


Il. OVERVIEW 


Intel’s FORTRAN-80 compiler is an implementation of 
the standard FORTRAN known as ANS FORTRAN 77 
approved by the American National Standards Institute 
(ANSI) in April, 1978. The implementation is of the 
FORTRAN 77 subset, plus most of the full I/O capabil- 
ity and Intel defined extensions. For a fuller description 


of the implementation, consult the FORTRAN-80 Pro- 
gramming Manual. 


FORTRAN-S80 is a high level applications program- 
ming language with flexible I/O handling and floating- 
point math instructions. With the FORTRAN-80 lan- 
guage, the programmer can easily implement sophisti- 
cated applications involving scientific calculations, 
process and instrument control, test and measurement, 
and a host of other applications requiring the power 
and flexibility the FORTRAN-80 language provides. 


With the addition of the iSBC 801 FORTRAN-80 
RUN-TIME PACKAGE for RMX/80 SYSTEMS, the 
user who wishes to implement his application using 
Intel’s Single Board Computers and the RMX/80 Real- 
Time Multitasking Executive can take full advantage of 
the FORTRAN-80 I/O and math capabilities. ‘The pack- 
age allows the user to accelerate the run-time execution 
of FORTRAN-80 coded mathematical formulae through 
special interfaces to the optional iSBC 310™ High 
Speed Mathematics Unit. All disk and terminal I/O is 
interfaced directly to the RMX/80 Disk File System and 
either the full or the minimal Terminal Handler. The 
libraries that comprise the iSBC package are construc- 
ted in a modular fashion, allowing the user to configure 
systems with as much or as little of the support libraries 
as needed for a given application. 


In order to effectively utilize the hardware and software 
products now available, it is important to design the ap- 
plication system from the top down. This implies that 
we need to think of an application in very general terms 
and then successively introduce more detail until we 
have program code as our final step. At each stage of 
the definition, we have to make decisions about the us- 
age and configuration of various products. 


NO 


FORTRAN 


80 


RMX/80T™ 
APPLICATION 


PL/M ASM FORTRAN PL/IM 
80 80 80 80 
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The decision-making process that concerns itself with 
software can be shown as a tree (Figure 1). The first 
decision that must be made is. whether or not the 
RMX/80 Real-Time Multitasking Executive should be 
utilized: In: general, this package will prove extremely 
useful if the application to be designed must.respond to 
multiple asynchronous events, or contains multiple, 
semi-independent processes that could be executed in 
parallel, or has need of standard vendor supplied device 
drivers. If the application is very small and simple, 
handles few or no interrupts, has no need for parallel 
execution of multiple processes, and the designer is 
willing to supply his own I/O device drivers, the pro- 
gram may be able to execute without the support of an 
operating system. 


Whether the RMX/80 picaee is used or not, the eis 
designer must now choose: in which language or 
languages the programs should be coded. Each of the 
three languages shown is optimized for different pur- 


poses. The PL/M-80 language is well suited for systems. 


programming. The ASM-80 language is best suited for 
applications requiring direct control of the computer 
(e.g., the registers and memory). The FORTRAN-80 
language is highly desirable for those applications 
requiring mathematical calculations and formatted 


NON-RMX/80TM 
FORTRAN-80 


0 
SUPPORT 


INTERNAL 
_ BUFFER 
FORMATTING. . | 


USER HIGH- 
_ LEVEL DRIVERS 


I/O. In many cases, the optimal solution will use a mix 
of two. or even all three of these languages. _ : 


III. USING FORTRAN-80.__ 


L/O Capabilities 


After the decision has been made to use the FORTRAN- 

80 language for an application, various types of I/O 
support are available to the user (see Figure 2). If the 

program code is to run without any support from an 

operating system, the user must supply drivers for any 

devices he wishes to include in his system. 


When designing an RMX/80 system, the iSBC 801 sack: 
age supplies the standard interface to the disk and 
terminal while the user may support additional devices - 
in the same manner .as the “stand alone” program 
would. The following sections expand on the topic of: 
FORTRAN-S80 I/O support. 


Port I/O 


The simplest and most direct method of performing I/O 

in the FORTRAN-80 language uses two pre-defined sub-. 
routines, INPUT and OUTPUT. The example below il- 
lustrates the use of these subroutines to input bytes from 

and output bytes to any of the 8080A/8085A I/O ports. 


RMX/80T™™, 


FORTRAN-80 


0 
SUPPORT 


RMX/80T NON 


RMX-80TM 
DISK FILE 
SYSTEM 


STANDARD 
DEVICES 


TERMINAL 
“HANDLER 


PORT W/O 


INTERNAL 
BUFFERS 


‘USER HIGH. 
LEVEL DRIVERS 


Figure 2. The I/O Support Decision 
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INTEGER* | IVAL 


C 
C -- PROGRAM THE 8255 PARALLEL I/O CHIP 
C -- PORT # = EB; VALUE = 94 


C 
CALL OUTPUT (#0EBH, # 94H) 
e 
e 
e 
C 


C -- INPUT 8 BITS FROM PORT A INTO IVAL 
C -- PORT # = E8; VALUE INPUT TOIVAL 
C 

CALL INPUT (#0E8H,IVAL) 


Port I/O is extremely useful in many applications. How- 
ever, this method requires the programmer to directly 
handle each and every byte. Also, it does not utilize the 
power of the FORTRAN-80 formatting routines. 


Internal Buffer Formatting 


One method of overcoming the shortcomings of Port 
I/O is to use character strings as “‘virtual devices.”’ This 
is accomplished by specifying a character string as the 
unit number in a READ or WRITE statement. External 
routines can be used to fill the character strings with 
input for the READ statement and to output buffers that 
have been formatted by the WRITE statement. The ex- 
ample below shows the use of this method. 


SUBROUTINE EXAMPL 
CHARACTER* 80 BUFFER 


C 
C -- CALL DEVICE DRIVER TO GET BUFFER OF 
C -- CHARACTERS 
C 
CALL BUFIN (BUFFER) 
C 
C-- NOW READ FROM BUFFER INTO VARIABLES 
C-- UNDER FORMAT CONTROL 
C 
READ (BUFFER, 100) X, Y, Z 
100 FORMAT (F 10.3, F12.4, F13.5) 


e 
¢ PROCESS DATA STORED IN VARIABLES 
eX, Y,Z | 
e 
C 
C-- WRITE RESULTS TO BUFFER 
C 


WRITE (BUFFER, 200) A, B, C, D 
200 FORMAT (4F 12.3) — 
C 
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C -- CALL DEVICE DRIVER TO OUTPUT BUFFER 
C 
CALL BUFOUT (BUFFER) 


User Provided High-Level Drivers 


If an application requires only simple input (READ) and 
output (WRITE) capabilities, the previous method 
would probably be sufficient. If, however, the device(s) 
in the system are more complex, it may be necessary to 
perform other I/O operations. One way of doing this 
would be to write subroutines for each operation. A 
much nicer solution is to use the FORTRAN-80 I/O in- 
structions (OPEN, CLOSE, READ, WRITE, PRINT, 
BACKSPACE, REWIND, and ENDFILE) to interface 
to user-written routines which implement these instruc- 
tions for the special device. 


This is possible because, for each open file in the system, 
the FORTRAN-80 I/O system keeps a table connecting 
the unit number with the addresses of the routines that 
handle all operations on that unit. The I/O system 
allows the user to substitute his own device drivers into 
this table. To do this, the system designer codes a 
routine and labels it FQOLVL. This routine is then 
made known to the I/O system (i.e., declared PUBLIC). 
Whenever a file is first accessed (i.e., OPENED), the I/O 
system calls FOOLVL with a set of parameters, one of 
which is the file name referenced in the OPEN state- 
ment. The designer, in his code for FOOLVL, scans the 
file name to decide if this is one of the files for which he 
wishes to supply drivers. If so, he passes back a table of 
the addresses of the routines that will take care of the 
eight primitive file I/O capabilities (refer to the example 
following this paragraph and to the FORTRAN-80 
Compiler Operators Manual). 


FOQO@LVL: PROCEDURE (fileSptr,buf$ptr) BYTE PUBLIC; 


/* table of entry point addresses for driver routines */ 


DECLARE table (8) ADDRESS DATA ( 


-openShdlr, /* address of OPEN routine */ 
-closeShdlr, /* address of CLOSE routine */ 
-readShdlr, 7* address of READ routine */ 
ewriteShdlr, 7* address of WRITE routine */ 
ebackShdlr, /* address of BACKSPACE routine */ 
-mv2recShdlr, /* address of MV2REC routine */ 
-rewindShdlr, /* address of REWIND routine */ 
address of END OF FILE routine */ 


emakeSeof$hdlr /* 
i 


DECLARE (returnedS$status,index) BYTE; 
DECLARE (file$ptr,buf$ptr) ADDRESS; 
DECLARE buf BASED bufSptr (1) BYTE; 
DECLARE fileSname BASED fileSptr (1) BYTE; 
DECLARE analogSin (*) BYTE DATA(':AI:'); 


/* set flag initially =FFH */ 
returned$status=GFFH; 
/* if any character of fileSname does not compare set flag=@ */ 
DO index=@ TO 3; 
IF filename(index) <> analogSin(index) THEN 
returnedSstatus=6; 
END; 
/* if flag=FFH pass back the addresses of the drivers */ 
IF returned$status=@FFH THEN 
CALL move(size(table),.table,buf$ptr) ; 


RETURN returnedSstatus; 
END; /* of FQOLVL */ 
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RMX/80™ Support 


When using the RMX/80 Executive, the iSsBC 801 
FORTRAN-80 RUN-TIME PACKAGE for RMX/80 
SYSTEMS can be used to provide a direct interface to 
standard RMX/80 high level drivers, the Disk File 
System and the Terminal Handler. With the RMX/80 
Executive, users can code multiple, concurrently 
executing programs that perform formatted I/O to disk 
files and the console, as shown in the following 
example: a 


C 
C -- OPEN disk file 
OPEN (8,FILE = ’:D0:TSTDTA.FIL’,ACCESS = 
‘“SEQUENTIAL’) 
Cc. | , 
C -- perform tests 
C 
e 
e 
e 
C 


C -- WRITE results to file for archival storage 
C 7 
WRITE(8,100) (RESULT (I),I = 1,10) 
100 FORMAT(LOF 12.3) 
C 
C -- PRINT completion message on console 
C | 
PRINT 200 
200 FORMAT (‘TESTS COMPLETE’) 


If it is necessary for a FORTRAN program in the 
RMX/80 system to perform I/O to a device not handled 
by one of the high level drivers, any of the methods pre- 
viously described can be utilized to augment the I/O 
system. 


FORTRAN-80 Math Capabilities 


The FORTRAN-80 language supports four data types 
labelled INTEGER, REAL, LOGICAL, and CHARAC- 
TER. Also supported are various operators which can 
manipulate objects of various types. Both INTEGER 
(fixed point) and REAL (floating-point) objects can be 
manipulated by the add (+), subtract (—), multiply (*), 
divide(/), and exponentiation (* *) operators. In addition, 
Integers can be operated on by the Boolean operators 
(e.g., .AND.,.OR.). In this case, the operations are per- 
formed bit-wise on the operands. : 


All floating-point arithmetic operations are performed 
with algorithms that adhere to the Intel Floating-Point 
Standard! which allows for seven decimal digits of pre- 
cision. Whenever math operations are used, the user 


can make the decision to use a software package to 
implement the floating point support or to accelerate the 
execution of these operations (by as much as a factor of 
five or six) by installing an iSBC 310 High-Speed Mathe- 
matics Unit and linking in special FORTRAN-310 
drivers. In either case, due to the adherence to the 
standard, the results of all calculations will be identical. 
In addition, the libraries have been designed to allow the 
switch to be made from software routines to a faster hard- 
ware solution with no code changes. 


Above and beyond the basic mathematical operators in 
FORTRAN-S80, a large number of intrinsic functions 
are available. These functions provide services like type 
conversion, remaindering, and logarithmic and trigo- 
nometric calculation. Since the calculations involved 
in performing these high-level functions require the 
mathematical operators, they too can be accelerated by 
the inclusion of the iSBC 310 board and its associated 
drivers. 


Error Handling 


The math processing system also provides flexible error 
handling. The user can choose to use either an Intel- 
supplied error handler or one of his own design. The 
capability also exists to change the active error handler 
dynamically in cases where different routines require 
different handlers. The default error handlers are named 
FOFERH. One exists in each of the arithmetic libraries 
(Figure 3). This error handler will attempt to recover 
from an error by taking the most reasonable action (e. g., 
underflow error returns result = 0). If code is being run 
‘stand-alone’ or under the RMX/80 executive the 
handlers in the math libraries should be used or the user 
should supply his own. Appendix B of the ISJS-IJ FOR- 
TRAN-80 Compiler Operator’s Manual contains all of 
the information necessary to implement a custom error 
handler or to use the default routines. 


FPSOFT.LIB_ - Software package for “stand-alone” 
and ISIS-II systems 


FPHARD.LIB 


- iSBC 310 drivers for same 
*FPSFTX.LIB = - Software package for RMX/80 systems 
*FPHRDX.LIB -iSBC 310 drivers for iSBC 80/20, 


80/20-4 and 80/30 boards 


*FPHX10.LIB_ -iSBC 310 drivers for iSBC 80/10 and 
80/10A boards 
FPEF.LIB - Library of routines implementing 
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intrinsic functions 


*Available in isBC 801 FORTRAN-80 RUN-TIME 
PACKAGE for RMX/80 Systems. — 


Figure 3. Available Math Libraries 


1 Palmer, John F., ‘The Intel Standard for Floating-Point Arithmetic,’ Proceedings of the 
First International Computer Software and Applications Conference (Chicago: IEEE Com- ° 
puter Society), November, 1977, pp 107-112. 
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IV. APPLICATION EXAMPLE 
An Automated Test Stand 


This example shows the steps taken to design and imple- 
ment an automated test stand. The hardware system 
must interface to a test fixture upon which test items can 
be mounted. Operator inputs and test outputs involve a 
300-baud hard copy terminal. The software to be devel- 
oped must allow an operator to invoke a variety of tests 
from the console and to receive some printed perfor- 
mance record for the object under test. In addition, the 
software must allow for tests to be added and deleted 
often, and each test must be allowed to obtain any 
number of parameters from the command line tail. 


After examining the problem definition and the decision 
making diagram presented earlier, it was decided that 
this application could be implemented with a simple 
sequential program. 


Since formatted I/O and mathematical calculations 
are involved, the FORTRAN-80 language is well suited 
to be the main programming language. Also, some 
ASM-80 routines will come in handy for communicating 
with the console. 


An analysis of the I/O to be performed breaks down into 
two distinct types. Various inputs to and outputs from the 
text fixture will be 8-bit parallel transfers. These will 
likely go through the 8255A ports on the Single Board 
Computer. Port I/O will be used to handle this function. 
Interface with the operator requires READ’S AND 
WRITE’s to the console device. The simplest way of per- 
forming this function is to use character strings as the 
target of READ and WRITE operations and coding small 
ASM-80 routines to transfer these buffers from/to the 
console. — 


A diagram of the test stand is shown in Figure 4. The 
computer hardware necessary to solve this application 
includes a Single Board Computer (the iSBC 80/20 
board), a PROM memory module and an analog I/O 
board. Digital I/O with the test fixture is handled by the 
8255A ports on the Single Board Computer. The analog 
inputs on the test fixture come from the two D/A conver- 
ter channels on the iSBC 732 board. 


The software solution utilizes a very rudimentary com- 
mand line interpreter. The mainline routine gets a line 
of input and finds the first non-blank character. If this 
character is an alphabetic character, it is used in a 
computed GOTO statement to transfer control to one 
of a possible 26 entry points. Tests may be added by 
choosing a keyletter and inserting a label in the GOTO 


statement to transfer control to the new test routine. The 


command input line and the index in the line are stored 
ina common block so that any test routine can continue 
scanning the line for parameters or can reset the index 
and find out what keyletter caused its invocation. The 
flow of the software is illustrated in Figure 5: 


For the purpose of explanation, routines are shown to 
implement a “calculator mode” which allows the opera- 
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tor to perform arithmetic from the console, and a logic 
transition tester which determines whether the object on 
the test fixture changes state at the proper voltages. 


COMPUTER 
SYSTEM 


DIA 
TEST 
FIXTURE 
Figure 4. Test Stand Diagram 
Code Description 


The following sections describe the program code for 
this application example. Fold-out code listings are con- 
tained in Appendix A. The circled reference letters in 
the text refer to the corresponding letters in the listings. 


The DRIVRS Module 


The module DRIVRS contains three primary routines. 
START (A) is located at 0 so that it is executed upon 
power up. This routine is responsible for programming 
the on-board hardware (8255A, 8251, 8253), setting up 
the system stack, and calling the FORTRAN routine 
labeled MAINLN. 


The input routine BUFIN is called from 
FORTRAN routines with a character string as an argu- 
ment. Note that passing a string argument from FOR- 
TRAN results in the address and length of the string 
being sent as parameters. The string is filled with char- 
acters input from the console until a carriage return is 
encountered. A simple line-editing scheme is imple- 
mented allowing character deletion (RUBOUT), line de- 
letion (CONTROL-X), and echoing of the current buffer 
contents (CONTROL-R). Attempted entry of characters 
beyond the end of the string and RUBOUTS eds the be- 
ginning cause the audible bell to sound. 


AFN-01931A 


The output routine, BUFOUT ©). , also takes a char- 
acter string as an argument. The entire contents of the 
string are sent to the console unless a carriage return is 
encountered in the string. If a carriage return is the ter- 
minator, a line feed is output as well. If a CONTROL-S 
is entered at the console while output is in progress, 
output is suspended until a CONTROL.-O is typed. 


INITIALIZE 


OUTPUT 
BANNER 


GET 
COMMAND 


GET FIRST 
NON-BLANK 
CHARACTER 


ALPHABETIC 
CHARACTER 
9 


ERROR © 
MESSAGE 


GOTO 
PROPER 
ROUTINE 


Figure 5. Flow Diagram 


The MAINLN Module. 


The module MAINLN- ©) contains he sanialine rou- 
tine that implements the command line interpreter. The 
statement IMPLICIT LOGICAL A-Z will cause. most 
usages of undeclared variables to be reported as illegal 
mixed. mode: the intent in writing these programs. was 
to declare all variables, which is generally considered 
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good programming practice, even though Fortran 
makes default assumptions about undeclared variables. 


The default handler is to be used for any errors that 
may occur while performing mathematical calculations. 
Also, the routines that perform the calculations must be 
initialized. Both of these operations are performed by 
the call to FOFSET (® . The call takes two arguments. 
The first argument is a two byte field specifying which 
error handler is to be used. If the low order bit of the 
high order byte is a one (e.g., 100 hexadecimal), the 
math routines will call a user error handler whose 
address is given as the second parameter. If the low 
order bit is zero (as is the case in this example), the 
routines will use the default handler and ignore the 
second argument. : 


A banner is output to the console by the sequence at 

where a formatted WRITE is performed on an 
internal buffer (IMAGE) and then the external driver 
BUFOUT is called to output the buffer to the console. 
The variable CARRET is ‘used to insert a carriage 
return into the string to be output. In order to allow in- 
dividual characters in the character string to be accessed, 
the EQUIVALENCE statement is used to cause 
LINBUF and IMAGE to occupy the same memory 
space. The variable INDEX G) is used to scan 
through. the input buffer. 


A call to BUFIN ) fetches the command line from 
the console. DBLANK is called qd) to position INDEX 
to the first non-blank character. This character is con- 
verted to its integer representation, normalized to | and 
checked to:see if it is a valid alphabetic character 

If the keyletter is valid, the computed GOTO (kK) 
causes execution to branch to the correct point in a 
jump table © . Note that A (add,) S (subtract), M 
(multiply), and D (divide) all branch to a single routine 
MATH, T (transition test) branches to a routine called 
TRANST and all other keyletters are trapped into line 
100. Any and all I/O errors cause the ERROR routine to 
be called. | 


The DBLANK Module 


The DBLANK routine ™) -de-blanks the input line. If 
a carriage return is encountered, the operator is 
prompted for more input. | 

The ERROR Module 


The ERROR routine @®) prints out an error message, 
with the error number, to the console. | 


The MATH Module 


In many of the tests, the human operator must supply 
numeric parameters. A calculator mode is supplied for 
the simple calculations that might be needed here. This 
mode is implemented through the MATH routine 

Since any one of four keyletters could have caused this 
routine to be invoked, MATH rescans the command line 
to obtain the keyletter (P) . Following this, two oper- 
ands are read in by calls to CONVRT and the: 


operation requested is performed on them. 
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The CONVRT Module 


Subroutine CONVRT (R) is called from other routines 
to extract floating-point operands from the input line 
buffer. Characters are transferred into a temporary 
buffer (S) until either a carriage return or a comma is 
encountered. The temporary buffer is then read under 
format control to obtain the returned value 


The TRANST Module 


The item to be tested is composed of combinatorial 
logic as shown in Figure 6. The transition test sets all 
inputs except one to a constant value. By varying the 
voltage at the remaining input, the transitions at the 
output can be checked. This test must be run while the 
+5V power to the fixture is varied through a range of 
values. This testing is performed by the TRANST 


routine. 


Power is supplied to the test fixture through one of the 
two D/A channels on the iSBC™ 732. Three of the input 
parameters specify the starting and stopping voltage 
values for Vcc and the increment to be added each step. 
The fourth parameter is the tolerance to be used to 
decide if the test passes or fails at each step. Once the 
test is running, the output voltage at (2) is measured 
for inputs at C) of 0 and 5V. The voltage input is then 
incremented from OV (using D/A channel 1) until a 
transition is sensed in the output voltage at (2) . At 
this point, the input voltage at dd) is checked to see if 
it is within tolerance. The same process is then repeated 
with the voltage at going from +5V downward. 
After the test is complete, a formatted report is 
generated containing the ambient temperature 
(measured through a temperature sensor) and the per- 
formance record for the item under test. 


TESTINPUT (1) TEST OUTPUT (2) 


COMBINATIONAL 
LOGIC 


LOW TO HIGH TRANSITION ALL OTHER 
INPUTS 
HELD 


CONSTANT 


HIGH TO LOW TRANSITION 


VOLTAGE 
VOLTAGE 


TIME 
Figure 6. Transition Test 


TEST STAND VG. 
COMMAND? 
M 34,678,345. 43 


34.5780 * 245.43200 = 11978.82164 


COMMAND? 
DP ae cope ce Oe 
TRANSITION TEST 


TOLERANCE= 5.7% AMBIENT TEMPERATURE = 25.36 DEGREES C 


VCC HIGH TRANS LOW TRANS HIGH LOW TEST 
445 G@.81  eh2 4.43 0.12 PASSED 
4.7 GH.80 3.44 4.67 G.28 PASSED 
4.9 2.80 a os 4.88 8.42 PASSED 
oye GB.80 S671 4.93 0.62 PASSED 
Sree: OF.86 — 33> 4.98 O.@1 PASSED 
Seo %2.80 Be 74. 4.99 G.@1 PASSED 
COMMAND? 
Figure 7. Sample Output 


2-41 AFN-01931A 


An external routine ) 
samples.into the variable given as the first parameter 
from the channel given as the second parameter. ‘The 


counts from the temperature sensor exhibit a logarith- 
mic curve, so the input is linearized using the equation 


shown. The routine DACOUT takes the first para- 
meter and outputs it to the channel specified by the 
second parameter. If no transition occurs when the test 


input is run through its entire range, the item is assumed 


non-functional, a message is output, and control is re- 
turned to the console : 


The ADCIN Module 


Subroutine ADCIN &) fetches samples from the A/D 
converter on the iSBC 732 board. The channel number 
is an input parameter and the data is the returned value. 
Of special note in this routine is the use of the FORTRAN 
common block to control a memory-mapped device. 
The master CPU communicates with the iSBC 732 by 
way of memory read and write commands instead of 
I/O commands. The primary reason for this is the fact 
that the 8080A IN and OUT instructions operate on 
only 8 bits at a time whereas SHLD and LHLD instruc- 
tions can manipulate 16 bit operands. This is 
convenient when working with 12-bit inputs from the 
A/D and 12 bit outputs to the D/A. In the code, a 
common block is created which has the same makeup as 
the memory mapped registers on the iSBC 732 board. 
The common block will be origined at the address of the 
iSBC 732 by the ISIS-II LOCATE program. 


The DACOUT Module . 
Subroutine DACOUT @) makes use of the same com- 


mon block to output given values to a specified D/A 
channel. 


LINK and LOCATE 
The ISIS-II LINK command needed to pull together the 


individual pieces of this example is shown in Figure 8. 


After compilation, the object modules of all of the pre- | 


viously described routines are placed in the library 
FRTMOD.LIB by the ISIS-II Library Manager™. The 
LINK statement starts with the module DRIVRS.OBJ, 
which has one EXTERNAL reference, MAINLN. To 


, ADCIN,: is called to input — 


satisfy this reference, MAINLN.OBJ is linked in from 
FRTMOD.LIB and its EXTERNAL references cause the 
inclusion of other modules. 


The LOCATE command shown in pituts 9 is used to 
assign absolute memory locations to the code in the 
LINKED modules. The common block labelled ADC is 
explicitly assigned to FFFOH so that it will correctly 
overlay the memory-mapped space of the iSBC 732 
board. The ORDER statement is used to tell the locator 
in what order the various segments should be placed in 
memory. | - - 


LINK :F]:DRIVRS.OBJ, & 
:F1lsFRTMOD.LIB, & 
:FA:FE@RUN.LIB, & 
:F@:F8@NIO.LIB, & 
:F@:F8GISS.LIB, & 
:FQ@:FPEF.LIB, § 
2FO0:FPSOFT.LIB, & 
:F@:PLM8@.LIB & 
TO :F1:TSTND.LK@® PRINT(:F1:TSTND.LNK) MAP 


Figure 8. LINK Command for Test Stand Example 


V. USING THE FORTRAN-80 RUN-TIME PACKAGE 
FOR RMX/80™ SYSTEMS 


The iSBC 801 package provides I/O interface and math 
routines for users who are coding RMX/80 applications 
in the FORTRAN-80 language. In the following sec- 
tions, an overview of the RMX/80 system will be 
presented along with a discussion of the use of the iSBC 
801 package. This overview is not intended to be ex- 


_ haustive. If the reader is unfamiliar with the RMX/80 


package, he should gain from this section enough un- 
derstanding to comprehend the concepts in the example 
presented. If the reader is planning on implementing an 
RMX/80 system, the RMX/80 references in the front- 
piece should be studied carefully. 


LOCATE :F1:TSTND.LK@ PRINT(:F1:TSTND.LOC) MAP LINES SYMBOLS PUBLICS & 
ORDER(CODE DATA /LINE/ /ADC/) /ADC/(@FFFQ@H) STACKSIZE(#) CODE(#) 


Figure 9. Locate Command for Test Stand Example 
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Overview of the RMX/80™ Executive 


A large number of microcomputer applications require 
the ability to respond to events in real-time. The 
RMX/80 Executive provides the system software around 
which you can build a real-time multitasking applica- 
tion using Intel iSBC 80™ Single Board Computers. In 
addition, the RMX/80 package provides the application 
designer with various high-level drivers (such as a 
terminal handler and a disk file system) which make it 
easier to develop sophisticated applications software. 


The RMX/80™ Model 


At this time, it is appropriate to discuss the RMX/80 
model, or in other words, the general concepts upon 
which the RMX/80 Executive is built. Real-time 
systems, such as the RMX/80 system, provide the cap- 
ability to control and respond to events occurring asyn- 
chronously in the physical world. To handle these 
events, the application is broken up into smaller semi- 
independent pieces, and each of these pieces is brought 
into action to handle the event for which it is intended. 
Each of these independent program units is a task. The 
RMX/80 Executive manages the execution of these tasks 
in accordance with a user-designated priority scheme to 
insure that the highest-priority task in the system has 
control of the CPU. It is also necessary, in a system such 
as this, for these semi-independent program units (tasks) 
to communicate with each other. This communication 
may be for the purpose of synchronization, data 
passing, mutual exclusion or any other use that may 
arise. To facilitate inter-task communication, the 
RMX/80 model incorporates the notion of messages and 
exchanges. A message is a data structure that can con- 
tain an arbitrary amount of information to be commun- 
icated from one task to another. An exchange is a “‘mail 
box’’ where tasks may send messages to be picked up by 
other tasks. The primary operations (primitives) that 
accomplish message transfers in the RMX/80 system are 
RQOSEND* and RQWAIT™. Figure 10 diagramatically 
shows the interaction of tasks, messages, and exchanges 
and introduces the symbolism used to represent these 
RMX/80 concepts in the system design. 


Tasks 


Typically, a task will execute a section of code that per- 
forms some initialization and then enters an infinite 
loop performing some processing over and over again 
as shown in Figure 1 1. 


Each task in the system has a priority associated with it. 
The RMX/80 Executive uses this priority scheme to de- 
termine which ready task to run. The assignment of 
priorities to individual tasks is up to the system design- 
er, giving him the capability to tune his system by 
assuring timely execution of important functions. 


LEGEND: 


EXCHANGE C) 


TASK SENDING MESSAGE | }-O 
TASK RECEIVING MESSAGE O-| | 


TASK . TASK 
A B 


Figure 10. Task, Message, Exchange Interaction 


SUBROUTINE TASK 1 
C 
C -- DECLARATION OF VARIABLES HERE 
C 5 
C 


C -- INITIALIZE VARIABLES AND I/O PORTS 
C 


CALL OUTPUT (#0E8H,0) 
FLAG = 1] 

INDEX = 1 

COUNT = 0 

SUM = 0 


C 
C -- ENTER INFINITE LOOP 
C 
] 


CALL INPUT(#0E9H,IVAL) 


Figure 11. Task Loop 


*In order to differentiate RMX/80 procedures and data structures from the user’s, the names 
of system objects are always preceded by RQ. 
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‘Each RMX/80 task also has its own stack, and there is 
no system stack. Whenever a task must give up the pro- 
cessor (e.g., must wait for the occurance of an interrupt) 
all of the information necessary to reawaken it at some 
future time without affecting the results of it’s proces- 
sing is stored on its stack. 


Exchanges 


An exchange in the RMX/80 system is a data structure 
that contains pointers to lists of tasks and messages. 
Whenever a message is sent to an exchange where there 
are no tasks waiting, it is added to the list of messages at 
that exchange until a task accepts it. Similarly, if a task 
waits at an exchange for a message and there is no mes- 
sage in the list, the task is added to the list of tasks wait- 
ing at that exchange. In both cases, the tasks and mes- 
sages are serviced on a first come, first served basis. Fig- 
ure 12 shows the possible states an exchange may be in 
at a given time. 


OR | 
EXCH$X 


Figure 12. Exchange Lists 


Messages 


A message in the RMX/80 system is a contiguous section 
of memory of an arbitrary length. Information can be 
stored in the message prior to it being sent to an 
exchange where it will be accepted by another task. 


Configuration 


The configuration module contains various tables and 
PUBLIC variables that are accessed by the system at 
start-up time. All of the necessary information on the 
tasks and exchanges to be created and the disk file 


system to be utilized are contained in this section of 
code. Configuration modules can be coded in either 
PL/M or assembly language (for which there are macros 
included with the RMX/80 product.) : - 


Memory Usage . 

In systems using disk, it is necessary to ensure that cer- 
tain buffers used by the disk controller for Direct Mem- 
ory Access (DMA) are located in memory that is acces- 
sible to the disk controller. The buffers needed are allo- 
cated in a separate module called the controller addres- 
sable memory module. In the case of the iSBC 80/10, 
80/10A, 80/20, and 80/20-4 boards, this module should 
be LOCATED before being included in the LINK state- 
ment to make sure that it does not contain any RAM on 
the CPU board itself (and, therefore, not controller- 
addressable). This restriction does not apply to iSBC 
80/30 systems, since the isBC 80/30 board has a dual 
port bus allowing system access to on-board RAM. 


VI. APPLICATION EXAMPLE 


A Sewage Treatment Plant Control System 


In the early 1900’s, the most popular type of sewage 
treatment system was known as a Sequencing Batch 
Reactor. It provided excellent effluent quality, but as 
populations grew, the amount of control necessary to 
operate the plant became too great for human opera- 
tors, and a new type of treatment system came into use. 
This new system did not require such accurate control, 
but it also did not perform as well. With the passage of 
stricter and stricter water quality laws, and with the 
advent of low-cost, high powered microcomputer con- 
trol systems, a serious look is being taken once again at 
Sequencing Batch Reactors. | 


A diagram of the treatment system and its sensors and 
actuators is shown in Figure 13. The system usually 
consists of three tanks, with each tank having individual 
influent and effluent valves, mixers and aeration equip- 
ment. 


At any given time, all influent is being routed to one 
tank. When this tank is filled, the influent is routed to 
one of the other two. The full tank is agitated and 
aerated until the bacteria in the tank digest the sewage 
to within given limits. At this time, the mixer and _aer- 
ator are turned off and the contents settle. After a time, 
the supernatant fluid is drawn off leaving the layer of 
concentrated bacteria to digest the next batch. 


The computer control system necessary for controlling 
these reactors is shown in Figure 14. The system is res- 
ponsible for monitoring the various sensors and contact 


closures, maintaining archives of system status, logging 


reports upon command, activating operator alarms, 
and performing on-line control of the batch cycle. 
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FLOW BATCH REACTOR #1 


SENSOR 


ON/OFF 
VALVE 


INFLUENT 


SENSORS 


ON/OFF 
VALVE 


EFFLUENT 


PNEUMATIC 
POSITIONER 


FLOW 
SENSOR 


SENSORS 


Figure 13. Sewage Treatment System and Sensors 


Software 


An analysis of the functions that need to be performed 
by the software for this control system leads to a 
decision to use the RMX/80 Executive. Timely response 
to multiple asynchronous events is the main thrust of 
this application. A breakdown of the individual func- 
tions in the system would be: 

¢ data collection — gathers inputs from the sensors and 
contact closures and stores them where other routines 
can access them. Also, converts data from analog 
counts to engineering units. 

° on-line control — based on current sensor inputs 
determines whether aeration, agitation, discharge 
and fill should be on or off. 

¢ alarm scanning — compares current status values 
with setpoints and sets operator alarms if conditions 
are out of tolerance when effluent is on. 

¢ data logging — once every five minutes logs current 
system status into a disk file record. 

e real-time clock — maintains day, month, year, and 
time of day. 

* operator console handler — monitors operator con- 
sole to detect operator commands for time and set- 
point changes, report generation, alarm clearing, etc. 

© report generation — upon operator command, for- 
mats either the file corresponding to yesterday’ S oper- 
ation or today’s operation to the current moment. 


Each of these functions must be studied independently » 


before the decision on which language to use for each is 
made. The functions concerned with data collection, 
on-line control, and alarm scanning will be concerned 
with mathematical calculations. The functions concern- 
ed with data logging and report generation will have 
need of formatted disk and console I/O. These routines 
will thus be coded in the FORTRAN-80 language. 


As was mentioned earlier, the PL/M-80 language is a 
systems programming language. This means that it is 
optimized to deal with the concepts embodied in a high- 
level system such as the RMX/80 system. The program 
code that implements the real-time clock and operator 
console handler will be written in the PL/M-80 
language. In addition, various PL/M-80 support routines 
will be written to be called on by one or more of the 
FORTRAN-S80 routines. The purpose of these routines 
will be explained as they come up in the code descrip- 
tions following. 

Hardware 


The hardware used to implement this control system 

must perform the following functions: 

e inputting analog samples from the various sensors 

® outputting analog values to the pneumatic positioners 

® inputting digital values from the contact closures and 
operator console | 

* outputting digital values to the operator esntole and 
alarm panel 7 

® storing and retrieving data fori diskette files. 
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RUy 


OPERATOR 
CONSOLE 


Rien! 
COMPUTER a 
beamed 
eee 2 


CONTACT CLOSURES ay 


REPORT 
GENERATION 


PNEUMATIC 
POSITIONERS 


RELAYS 


DISK DATA STORAGE 


Figure 14. Computer Control System 


The hardware configuration chosen includes an iSBC 
80/30 Single Board Computer, an iSBC 732 Combina- 
tion Analog Input/Output Board, a combination of 
PROM and RAM memory modules, and an iSBC 201 
Diskette Controller. | 


There are various types of I/O devices in this system and 
each will require different FORTRAN-80 I/O support. 
The terminal and disk devices are supported through 
the iSBC 801 run-time package and the RMX/80 high 
level drivers. Communications with the A/D and D/A 
converters is accomplished using internal buffer 
formatting in conjunction with the RMX/80 Analog 
Handlers. Finally, port I/O is used for the digital inputs 
and outputs. 


The next step in the design is to assign the system soft- 
ware functions to individual tasks in a manner that will 
allow for their parallel execution. The following tasks 
will be created to handle this application: 


e STSINP — status input and unit conversion 

¢ CNTROL — on-line control 

e SCAN and TIMERS — alarm scanning and dats aa 
logging 

¢ TIMER and TIMUPD — real-time clock’ 

¢ CONSOL — operator console handler _ 

¢ REPORT — report generation ; 

Figure 15 shows the interaction of THESE tasks in the 

RMX/80 system. 


System Considerations 


At this point, let us consider some of the mechanisms this 
system will require to synchronize and co-ordinate the 
tasks we have created. Status and setpoint information 
will be stored in FORTRAN common blocks. This will 
allow the STSINP, CNTROL, SCAN, CONSOL, and 
TIMUPD tasks access to the STATUS information, and 
the CNTROL, SCAN, and CONSOL tasks access to the 
SETPNT information. Once per five minutes, SCAN will 
be notified through a flag byte (MINSUP) that he is to 
write the current system status to the file TODAYS.RPT. 
Upon command from the operator, REPORT wn need to 
read these files to generate reports. 


Since the RMX/80 system is designed to handle asynchro- 
nous events, it is quite possible for any of the tasks to be 
pre-empted at any point in their execution (e.g., an inter- 
rupt occurs or a higher priority task becomes ready to 
run). Thus, the SCAN task may be in the process of 
reading the last byte of a four-byte REAL integer when 
STSINP pre-empts the SCAN task and writes new infor- 
mation into the STATUS common block, thus inval- 
idating the current SCAN operation. In another instance, 
REPORT may be in the process of fetching a disk record 
when SCAN attempts to write to the file. For these 
reasons, and more, it is necessary to implement some sort 
of synchronization mechanism in this system. We will 
insure that at most, one task has access to the common 
blocks and disk records by using a technique called 


mutual exclusion. In the RMX/80 system, this is accom- 
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Figure 15. System Design Diagram 


plished by creating an exchange for each shared resource 
and initially sending one message to it. Any task 
requiring access to the resource first waits at the associ- 
ated exchange for the key message. If a message is at the 
exchange, the task obtains the message and continues 
running until finished and then sends the message back. 
If another task waits at the exchange while the first is pro- 
cessing, it will stop execution until the first task finishes 
and returns the message. 


Code Descriptions 


What follows is a description of the code used to imple- 
ment most of the tasks discussed. Appendix B contains 
fold-out code listings with circled reference letters. In the 
description, sections of the code will be called out using 


circled letters that correspond to symbols in the 
appendix. 
The Semmod Module 
Two PL/M routines called LOCK and UNLOCK perform 
the mutual exclusion operation discussed earlier. There 
are three exchanges used for the purpose of exclusion: 
STSLOK, SETLOK, and DSKLOK. They govern access 
to the STATUS common block, the SETPNT common 
block and the disk file respectively. The LOCK procedure 
takes one parameter, a number representing one of 
the three exchanges, and performs a wait at the appro- 
priate exchange. Note the use of based variables to access 
the parameter. This is necessary since FORTRAN passes 
parameters by reference (address) rather than by value. 
The UNLOCK procedure takes the same para- 
meter and sends the single key (message) back to the 
appropriate exchange. 7 
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_ These routines are written in the PL/M language because | 


they must deal directly with a few system concepts that — 


the FORTRAN-80 language does not. In particular, the 
RQWAIT routine returns to the caller the address of the 
message received from the exchange. In either the PL/M- 
80 or ASM-80 languages this address can be used to 
access the information in the message received. 


FORTRAN-80 routines do not have the capability to use 


address values to access data outside of their own 
module. 


The STSINP Module 


The module STSINP © performs the function of 
updating the STATUS common block with new data 
from the sensors that has been converted to engineering 
units. STSINP initializes the FORTRAN-80 math 
routines (D) and directs them to use the default error 
handler. STSINP then calls INIT$IO which initial- 
izes the message that will be used to communicate with 
the RMX/80 Analog Input Handler. The call to 
SMPLIN (F) fills the buffer with analog samples from 
the sensors, and the following DO loop right-justifies 
the 12-bit samples in the 16 bit field GC) . STSINP now 
waits for access to the STATUS block, converts the 
samples, stores them, inputs and stores the values of the 
contact closures and calls UNLOCK. (H) . The function 
performed by STSINP is not a continuous function. 
Update of the status information once per second is 
sufficient. The call to WAIT C1) delays execution for 
one second. : 


none eran 


Figure 16. Request Message for Sequential Channel In- 
put with Single Gain — | 


The ANALOG$IO$MOD Module 


In the module labelled ANALOG$IO$MOD, the declar- 
ation of READ$MSG @) uses the predefined LITERAL 
called AI$MSG. This LITERAL is one of many in the 
RMX/80 package that can be used to attach meaningful 
symbolic names to PL/M data structures. In this instance, 
AI$MSG defines the fields of a standard analog input 
request message. Figure 16 is a diagram of the individual 


fields of the request message. The definition and usage of 
each of these fields is described in the RMX/80 User’s 
Guide. The procedure INIT$IO is called by 
STSINP. It simply initializes the analog input request 


message and returns. Note the assignment operation in 


line 29. The RESPONSE$EXCHANGE field of the 


request message must contain the address of the exchange 


‘where the RMX/80 Analog Handler should send the res- 


ponse to the request (see Figure 17 for a diagram of the 


-request-response mechanism). In the PL/M language, this 


address is assigned using a location reference - a variable 
name preceded by a period, which stands for the address 
of the variable. FORTRAN-80 routines lack the ability to 
refertothe address of variables. _ | 


RQAOEX 


—anacoae =F 
HANDLER 


Figure 17. Request/Response Mechanism 


The procedure SMPLIN () fills in a buffer, given as an 
input parameter, with analog samples from sequential 
channels on the A/D. Note the mechanism used to handle 
the passing of a FORTRAN string as a parameter. For 
every string in the parameter list, FORTRAN passes the 
starting address. of the string followed by its length in 
bytes. 


_ Figure 18. Use of EQUIVALENCE Statement. 
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The SCAN Module 


The SCAN task is responsible for operator alarms and 
data logging. The EQUIVALENCE statements | 
cause the STATUS common block to be overlaid by a 
character string, as illustrated in Figure 18. This allows 
for a compact file on disk of numerical data which can 
be broken out later for report generation. 


After initialization, SCAN waits for access to both the 
STATUS and SETPNT common blocks. Operator alarms 
need to be set only if a parameter is out of specification 
and the effluent pump is on . After performing the 
scan, the variable MIN5UP is checked ©) to see if a 
report should be logged. If so, SCAN gains access to the 
disk file and writes a single record . All locks are 
now released, a one-second delay is counted out, and 
SCAN repeats the whole process. Normally, any errors 
that occur during the execution of I/O statements in the 
run-time package cause a message to be output on the 
console and the offending task to be suspended. Since this 
action is often undesirable, it is wise to handle one’s 
errors programatically ©) 


The MIN$5$MOD Module 


The module MIN$5$MOD contains two procedures. 
Both routines make use of the timed wait facility in the 
RMX/80 system. Any time a task calls RQWAIT to wait 
for a message at an exchange, an optional time limit (in 
50 msec. intervals) can be specified. This is useful if the 
designer does not wish the task to be hung up forever if 
a message is never sent to that exchange. This mechan- 
ism can also be used to implement a timed wait if an 
exchange is specified to which no one will ever send a 
message. WAIT (R) delays execution of the calling 
task for one second. TIMERS (S) waits for five 
minutes and then sets the variable MIN5SUP to signal 
SCAN to log a disk record of current status. 


The REPORT Module 


The system console contains two buttons, one each for 
requests for printouts of today’s and yesterday’s status 
reports. Whenever one of these two buttons is pushed, the 
CONSOL task sends a message to the PRTREQ 
exchange with the TYPE field indicating which file to 
print. REPORT accepts these messages, checks the TYPE 
field (L) , and calls the FORTRAN subroutine PRINT 
with the appropriate filename as a parameter. It then 


returns the request message to its sender via the response 


exchange field and waits for another request. Figure 19 is 
an example of the report generated by this system. . 


The PRINT Module 


The PRINT subroutine will read in the compressed 
records written by SCAN and use the same set of EQUIV- 
ALENCE statements to break out the numerical data so 


that it_can be formatted for printout. If the type 
field (U) indicates that today’s file is being accessed, 
PRINT obtains the key to the DSKLOK exchange since 
SCAN may disturb output operations if it attempts to log 
a new record. If yesterday’s file is being accessed, the lock 
is not necessary, since no other task will be accessing this 
file. Once the lock is obtained, a record is read, the digital 
value of the contact closure status is converted to a more 
readable form (ON or OFF), and the status line is 
formatted and printed. Since the SCAN task has an 
important function (operator alarms), we do not wish to 
hold it up for long if it happens to want to log a new status 
record. For this reason, PRINT relinquishes access to the 
file after every tenth record to allow SCAN_to log its 
record and continue on. The rest of the code checks 
for end of file indications and ‘returns when printing is 
finished. _ 4 
The INITMOD Module 


Last in order (but first in execution) is the INIT proce- 
dure. It is called from the TIMER task, which is the 
highest-priority task in the system (and thus, will be the 
first to execute after start-up). INIT’s role in life is to call 
FQ0GO (X) to initialize the FORTRAN I/O_system, 
send one message to each of the lock exchanges , and 
initialize the operator alarm panel (Z) . The call to 
FQOGO isa requirement for an RMX/80 system in which 
any FORTRAN-80 code that makes use of the iSBC 801 
package is to be executed. The call must be made prior to 
the execution of any FORTRAN-80 I/O or math instruc- 
tions. Also, the call to FQOGO should only be made 
once. 


DATE TIME PH VOLUME _ TEMP DISSOLVED TOTAL ORGANIC 
oe ‘ OXYGEN CARBON CARBON 
(CU.M) (C) (MG/ML) (MG/ML) (MG/ML) 
9/19/78 8: 5: 8 6.1 2012.32 25.4088 12.3468 76.9888 34.0876 
9/19/78 8:18: 86 6.2 2614.68 25.4880 12.54¢8 88.0348 49.4933 


SUSPENDED PHOSPHATE INFLUENT EFFLUENT TURBID AIR DIS MIX INF 
SOLIDS CONC FLOW FLOW 
(MG/ML) (MG/ML) (MG/ML) (MG/ML) % 
16.0987 56.9808 112.898 @.680 74.56 ON OFF ON ON 
19.3943 61.4388 119.346 6.088 86.43 ON OFF ON ON 


Figure 19. Sample Output 


SYSTEM GENERATION 


Configuration Module | 


Now that all of the code for the individual tasks is written, 
it is time to generate the tables that give the RMX/80 
Executive the information it needs to configure all of the 
tasks and exchanges. Assembly language macros are in- 


~ cluded in the RMX/80 product to help make building 
~. the configuration module a little easier. After the 


counters have been initialized, the STD macro is invoked 
several times to define Static Task Descriptors for the 
tasks in the system. Of special note are the last two entries 

. Any task that uses the FORTRAN I/O system 
must allocate approximately 800 bytes of stack. This 
extra stack space is needed to save information on the 
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current I/O: operations. Also, any task performing 
floating point calculations with the software package 
needs to append ¢ an extra 18 bytes to its Task Descriptor 
as a workspace area. If the iSBC 310 drivers are used 
this need be only 13 bytes long. This last field is de- 
fined by passing a value of 13° or 18 to the optional 
parameter, TDXTRA, in the STD macro. The routines in 
the FORTRAN-80 Run-Time Package require one ex- 
change, FOOLOK, ‘which is allocated using the XCH 
macro (BB) , and added to the Initial Exchange Table 
by the PUBXCH macro : | 


Controller Addressable Maas Module | 


The CAMMOD module ©) allocates the blocks of 
memory needed. by the RMX/80.-Disk File System. 
Specific details on the contents of this module can be 
found in the RMX/80 User’s Guide. __. 


LINK 


Figure 20 shows the ISIS- I LINK command aisedl to bind 
all of the individual modules together with the RMX/ 80 
libraries needed to implement this application. The 
FORTRAN- 80 I/O. interface routines are found in the 
library F80RMX. LIB which i is part of the iSBC 801 pack- 
age. the library FPSFTX. LIB contains the software 
“floating point package. If it is desired to accelerate the 
execution of the mathematical operations in this system, 
the iSBC 310 board can be included and the library 
changed to FPHRDX.LIB for iSBC 80/20, 80/20-4, and 
80/30 systems or FPHX10. LIB for iSBC 80/10 and 
80/10Asystems. 


The RMX/80 extensions included are the Disk File Sys- 
tem, the Analog Handlers, and the Minimal Terminal 
Handler. | 


LOCATE _ ah | - 

After the Link has been finished, the command shown in 
Figure 21 is used to invoke the ISIS-I] LOCATE program. 
~~ ORDER statement sets the proper order for all o De 


LOCATE .. :Fl: ‘SEWAGE.LKG PRINT (: 


different segments and common blocks.’ The common — 


blocks ‘themselves are allocated. as fixed blocks of 


memory to make possible their shared usage by PL/M 
routines using the AT attribute. This mechanism is 
discussed in greater detail in. AP-44, “‘How to use 
FORTRAN With Other Intel Languages”. ' 


VII. SUMMARY ’ 


The | purpose of this application note has been to describe 


F is . SEWAGE. 


the design process used to decide what operating system 
support to use, what language to code programs in, what 
hardware to use and what type of I/O to use to solve a 
given application problem. The specific application ex- 
amples .presented have keyed on the use of the 
FORTRAN-80 language. 


The lesson that has been learned is that proper design 


techniques result in the use of the right tool for every job. 
With a'complete set of programming languages, each 
optimized for a specific use, a powerful real-time 
executive, and a complete line of flexible hardware 
products, complicated applications become easy to 
solve. 


:F@:RMX&83@.LIB(START) , 
2X2CFG.OBJ, & | 
:RPTMOD.OBJ, 
:FRTMOD.LIB, 
: INITMD.OBJ, 
:F8YRUN.LIB, 
:FE@RMX.LIB, 
2FPEF.LLIB, & 
:FPSFETX.LIB, & 

:SYSTEM.LIB, & | 
: DFSDIR.LIB (DIRECTORY, DELETE ,RENAME,SEEK) , 
:DIO83¢@.LIB, & 
:DFSUNR.LIB, & 

:CAM.OBJ, & 

+ PLMMOD. 
:AIHDLR. 
: AOHDLR. 
:MTI83@. 
:MTO83@.LIB, 
:F@:RMX830. LIB, 
: UNRSLV.LIB, 
:F@:PLM8@.LIB TO 


& 
& 
& 
& 
& 
& 


& 


LIB, 
LIB, 
LIB, 
LIB, 


EEN RY Ra a 


:F]:SEWAGE.LK@ PRINT(:F1:SEWAGE.LNK) MAP 


Figure 20. LINK Command for Sewage Treatment Example 


Loc) MAP & 


CODE (A). STACKSIZE(@) LINES SYMBOLS PUBLICS & 
ORDER (CODE DATA /LSTREC/ /STATUS/ /SETPNT/ /MINS/) /STATUS/ | 'FFA5H) & 


/SETPNT/ (FFDEH) /MINS/ (PFEEH) 


/LSTREC/ (FFA3H) 


- | Figure 21 ; LOCATE Command for Sewage Treatment Example | 
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ASM8@ :F1:DRIVRS.M8@ DEBUG PAGEWIDTH(78) PRINT (:F5:DRIVRS.LST) 


ISIS-II 8888/8885 MACRO ASSEMBLER, V2.@ ; DRIVRS PAGE 1 
LOC OBJ SEQ SOURCE STATEMENT 

1 NAME DRIVRS 
2; 
Zi FHEEEEEEEFF EAA EREEEE EEF EE FE EEE EEE FEE EEE FEET ETH H ttt ttt 
4; 
5; CONSOLE I/0 ROUTINES FOR FORTRAN-iSBC SYSTEM. 
6 ; START INITIALIZES THE HARDWARE AND CALLS THE 
73 FORTRAN ROUTINE MAINLN. BUFOUT ACCEPTS TWO 
8 ; PARAMETERS FROM THE CALLING FORTRAN ROUTINE 
9; (ACTUALLY ONE FROM THE ROUTINE SINCE PASSING 

18; A STRING ARGUMENT FROM FORTRAN RESULTS 

11; IN THE ADDRESS AND LENGTH OF THE STRING BEING 

12 ; SENT) AND OUTPUTS THE STRING TO THE USART 

13; ON THE &@/2@. BUFIN TAKES THE SAME TWO 

14 ; ARGUMENTS AND FILLS IN THE BUFFER WITH 

15 ; CHARACTERS UNTIL <CR> IS ENCOUNTERED. LINE 

16 ; EDITING IS PROVIDED TO THE EXTENT THAT 

17 ; RUBOUT DELETES A CHARACTER AND ECHOES IT, 

18 ; CONTROL-X DELETES THE BUFFER AND STARTS OVER, 

19 ; AND CONTROL-R PRINTS THE BUFFER CONTENTS. 

20 ; BUFOUT CALLS THE ROUTINE CHKIO TO DETERMINE 

21; IF A CNTL-S HAS BEEN ENTERED TO CAUSE A PAUSE 

22 ; IN THE OUTPUT. IF ENCOUNTERED THE ROUTINE 

23; WAITS UNTIL A MATCHING CNTL-Q IS ENTERED. 

24 ; 

25 FEPEEEFEERE EEE EE HEHEEEEE EEE EE EEE EEEEE EEE EEA HE EEE EEE EEE Et 
2BOD 26 CR EQU @DH ;ASCII CODE FOR CARRIAGE RET. 
OOGA 27 LF EQU GAH ;ASCII CODE FOR LINE FEED 
801B 28 ESC EQU 1BH ;ASCII CODE FOR ESCAPE 
8618 29 CNTLX EQU 18H ;ASCII CODE FOR CONTROL-~X 
OO7F 3@ RUBOUT EQU Q7FH ;ASCII CODE FOR RUBOUT 
0808 31 BS EQU 08H ;ASCII CODE FOR BACKSPACE 
8613 32 CNTLS EQU 13H ;ASCII CODE FOR CONTROL-S 
0811 33 CNTLOQ EQU 11H ;ASCII CODE FOR CONTROL-Q 
08607 34 BELL EQU 07H ;ASCII CODE FOR BELL 
@@12 35 CNTLR EQU 12H ;ASCII CODE FOR CONTROL-R 
®GED 36 CSTS EQU ®EDH ; USART COMMAND/STATUS PORT ADD 
OGEC 37 CDATA EQU MECH ;USART DATA PORT ADDRESS 
O81 38 TXRDY EQU 01H ;MASK FOR TRANSMITTER READY 
O82 39 RXRDY EQU 62H ;MASK FOR RECEIVER READY 
0848 4@ RESET EQU 40H ;USART RESET COMMAND 
OB4E 41 USMODE EQU SEH ;USART MODE WORD 
0627 42 USCMND EQU 27H ;USART COMMAND WORD 
OOB6 43 TIMCMD EQU O@B6H ;BAUD RATE CNTR COMMAND WORD 
0892 44 CMD55 EQU 92H 38255 COMMAND WORD 


GOODE 45 CNTR2 EQU ODEH BAUD RATE CNTR PORT ADDRESS 
O@DF 46 TIMCP EQU @DFH ;TIMER CONTROL PORT ADDRESS 
OVEB 47 PR8255 EQU OEBH 38255 COMMAND PORT ADDRESS 
A880 48 STKSIZ EQU 128 ;STACK SIZE 
O9EB 49 BDFCTR EQU 224 ;BAUD RATE FACTOR(COUNT VALUE) 
58 ; 
51 ; ALLOCATE STACK 
52 3 
LOC OBJ SEQ SOURCE STATEMENT 
5:3 DSEG 
O82 54 FRTSTK: DS STKSIZ 
55 ; 
56 ; LOCAL DATA STORAGE 
57 ; 
CAR2 58 BUFPTR: DS 2 ;BUFFER POINTER STORAGE 
59 CSEG 
68 ; 
61 ; START--STARTUP ROUTINE PROGRAMS THE USART 
62 ; AND TIMER THEN CALLS THE FORTRAN 
63 ; ROUTINE. IF THE FORTRAN ROUTINE 
64 ; RETURNS START SIMPLY STARTS OVER. 
65 ; 
66 EXTRN MAINLN 
OCB Z317F OD D 67 START: f° LXI SP,FRTSTK+STKSIZ-1 ;SET STACK POINTER 
@@@3 AF 68 XRA A ;ZERO ACCUMULATOR 
@@€4 D3ED 69 OUT CSTS ;BRING USART TO KNOWN STATE 
0006 D3ED 78 OUT CSTS ;BY SENDING FOUR NULLS 
@2@08 D3ED 71 OUT CSTS : 
OG0A D3ED 72 ‘ OUT CSTS f 
CF BC 3E4B 73 MVI A,RESET ;RESET USART 
COGE D3ED 74 OUT CSTS : 
@@18 32E4E 75 | MVI A, USMODE ;SEND USART MODE WORD 
@812 D3ED 76 OUT CSTS : 
0814 3E27 77 MVI A,USCMND ;SEND USART COMMAND 
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0216 
6618 
OB1A 
@@1C 
OQI1E 
HO26 
BA22 
B24 
A426 
6228 
@@2B 


BO2E 
G02F 
B22 
#031 
BAZ2 
0833 
8836 


0838 


8839 
88 3C 
OB3E 
0041 


Loc 
@H44 


9047 
9849 
B64C 
OO4E 
9051 
9052 
0055 
2057 
O25A 
005B 
@65D 
2060 


0063 
0864 
2867 
OB68 
BE69 
BB6A 
B26C 
006D 
2078 
0871 
2072 
0873 
8874 


6875 
6876 
2077 
0278 
0879 
@87C 
887D 
8280 
0882 
8883 
8886 
8887 
2888 
8289 
OS8A 
888D 
OB8E 
OO8F 


8698 


D3ED 
3EB6 
D3DF 
3EE@ 
D3DE 
3E@8 
D3DE 
3E92 
D3EB 
CDIAGB E 
C3880 Cc 


228078 D 


1686 
D5 
CDE208 Cc 


FE7F 
C2478 Cc 


CD9OAPA Cc 


OBJ 


C33960 Cc 


FE18 


CAA26@ Cc 


FE12 


CAF9BO Cc 


1D 


C26388 Cc 


FE@D 


CA630@ C 


4F 


71 


E5 
F5 
60 
69 


CDCD@B Cc 


4E 


CDB409 Cc 


3E@D 
B9 


15 


CA8DEO Cc 


122 


132 


134 
135 


138 
139 
148 
141 
142 
143 
144 
145 
146 
147 


148 


149 
158 


~e te Me 


B 


UFIN: 


GETCHR: 


Isl. 


152 
153 
154 


155. 


156 
157 
158 
159 
168 
161 
162 


OUT CSTS ; 


MVI A,TIMCMD ;SEND COMMAND WORD 

OUT TIMCP ; 

MVI A,LOW(BDFCTR) ;SEND LOW ORDER BYTE 

OUT CNTR2 ;OF COUNTER VALUE 

MVI A,HIGH(BDFCTR) ;SEND HIGH BYTE OF 

OUT CNTR2 ;COUNTER VALUE 

MVI ' A,CMD55 ;8255 COMMAND WORD 

OUT PR8255 ;PROGRAM 8255 

CALL MAINLN ;CALL FORTRAN ROUTINE 

JMP START ; IF ROUTINE RETURNS START OVER 


BUFIN--FILLS BUFFER WITH INPUT FROM TERMINAL 
PUBLIC BUFIN 


PUSH H ;SAVE HL PAIR © 


PUSH PSW :SAVE PSW 

PUSH B ;SAVE BC 

MOV H,B ;GET BUFFER POINTER TO HL 

MOV L,C ; 

SHLD BUFPTR ;SAVE IT 

MVI D,@ ;ZERO TO # CHARACTERS COUNTER 
;NOTE: STRING LENGTH <=255 

PUSH D ;SAVE COUNTERS 

CALL CI ;GET CHARACTER 

CPI RUBOUT ;RUBOUT? 

JINZ BUF@S ;NO, CONTINUE 


CALL DLTCHR ;YES,DELETE LAST CHARACTER 


SOURCE STATEMENT 


IMP GETCHR ;GET NEW ONE 
BUF@S5: 
CPI CNTLX ;CONTROL-X? 
JZ DLTLIN ;YES,DELETE BUFFER 
CPI CNTLR  ; CONTROL-R? 
Jz PRTBUF ;YES,PRINT BUFFER 
DCR E ;DECREMENT SPACE LEFT COUNTER 
INZ BUF1@  ;CONTINUE IF COUNTER > 6 
CPI CR ;IF THIS END OF LINE ALL IS OK 
JZ BUF10 
INR E ;BRING COUNTER BACK ONE 
MVI C,BELL ;NOT OK, ECHO BELL 
CALL ECHO ; 
JMP GETCHR ;GET NEW CHARACTER 
BUF16: . 
MOV C,A ;MOVE CHARACTER TO C 
CALL ECHO ;AND ECHO IT : 
MOV M,C ;STORE IT IN BUFFER 
INX H ; INCREMENT BUFFER POINTER 
INR D ; INCREMENT # OF CHARS COUNTER 
MVI A,CR ;IS IT A NEWLINE CHARACTER 
CMP Cc : 
INZ GETCHR ;NO,CONTINUE FILLING 
POP D ; YES, RETURN 
POP B F 
POP PSW ; 
POP H s 
RET ; RETURN 
F | 
; BUFOUT ENTRY POINT 
, 
PUBLIC BUFOUT 
BUFOUT: PUSH H ;SAVE HL REGISTER PAIR 
PUSH PSW ;SAVE PSW 
MOV H,B ;GET STRING POINTER INTO HL 
MOV - iL, C ; 
OUTCHR: CALL CHKIO  ;CHECK FOR PAUSE(CNTL-S) 
MOV c,M ;GET CHARACTER 
CALL ECHO ;OUTPUT TO TERMINAL 
MVI A,CR ;IS IT A <CR>? 
CMP Cc : 
JZ EXITLP ;YES,EXIT 
INX  H ; INCREMENT POINTER 
DCX D . ;DECREMENT STRING COUN 
MOV A,D ;GET HI BYTE | 
ORA E ;AND WITH LO BYTE 
INZ OUTCHR ;IF STRING COUNT <> @ CONTINUE 
EXITLP: POP PSW ;RESTORE PSW 
POP H ;RESTORE HL 
RET ;ALL THROUGH 
t 
; DLTCHR--DELETES LAST CHAR ENTERED INTO BUFFER 
es | 
DLTCHR: 


DCR D ;DECREMENT # OF CHARS COUNTER 
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LOC OBJ SEQ SOURCE STATEMENT | 
0091 F29B898 Cc 163 IP DLTC1@ ;IF >=@ CONTINUE 
9694 14 164 INR D -  $sRUBOUT PAST START OF BUFFER 
6895 @E87 - 165 MVI -C,BELL ;INCREMENT COUNT,ECHO A BELL. 
6097 CDB4E¢ Cc 166 CALL ECHO po 
OG9A C9- 167 _ RET ;AND RETURN 
168: DLTC1@: : 
@99B 1C 169: INR E ;INC. SPACE LEFT INDICATOR 
689C 2B 172 DCX H ;DECREMENT BUFFER POINTER 
889D 4E 171 MOV C,M ;ECHO DELETED CHARACTER 
- @B9E CDB48¢4 Cc 172 CALL. ECHO. ; 
@GA1 C9 173 RET ;AND RETURN 
174. ; 
175 ; DLTLIN--DELETES LINE BUFFER AND BEGINS REFILL 
176 ; 
177 DLTLIN: 
O@GA2 BE23 178 MVI c,'#' ;ECHO A '#! 
6@A4 CDB400 c 179 CALL ECHO 
68A7 SEBD 180 MVI CCR ;ECHO A CRLF 
@GA9 CDB489 c 181 CALL ECHO 
OBAC 2A800B D 182 LHLD BUFPTR ;GET ORIGINAL POINTER BACK 
B@AF Dl 183 POP D ;GET COUNTERS BACK 
O9@B6 DS | ; 184 PUSH D ;RESAVE 
6@B1 C3398 Cc 185 JMP GETCHR ;GET NEW CHARACTERS 
1846 ; 
187 ; ECHO--ECHOES CHARACTERS TO THE TERMINAL 
188 ; 
O2B4 41 189 ECHO: MOV B,C ;SAVE ARGUMENT 
6@B5 3£1B 199 MVI A,ESC ;SEE IF ECHOING AN 
69B7 B8 191 CMP. B ;ESCAPE CHARACTER 
68B8 C2BD6B Cc 192 JINZ ECH@5 ;NO--BRANCH 
O@OBB GE24 193 MVI C,'S! ;YES,ECHO AS 'S'! 
194 ECH@S5: 
8@BD CDEEGO Cc 195 CALL co sOUTPUT IT 
88CB 3E8D 196 MVI A,CR 
60C2 BB 197 CMP B ;CHARACTER ECHOED A CR? 
08C3 C2CBAB Cc 198 JINZ ECH1@ ;NO--SPECIAL ACTION NOT NEEDED 
68C6 BEAA 199 MVI C,LF ;YES--ECHO FREE LINE FEED 
98C8 CDEEGS C 200 CALL co 
201 ECH1O 
O8CB 48 202 MOV CLB ;RESTORE ARGUMENT 
BBCC CY 283 RET 
204 ; 
205 ; CHKIO--CHECKS FOR CNTL-S OPERATION 
206 ; 
@8CD DBED . 2@7 CHKIO: IN CSTS ;GET STATUS 
OECF E6G2 268 ANI RXRDY ;CHARACTER AVAILABLE? 
G0D1 C8 209 RZ :NO, RETURN 
8@D2 DBEC 210 IN CDATA ;YES,GET CHARACTER 
@@D4 E67F 215 ANI 7FH ;STRIP OFF PARITY 
86D6 FE13 212 CPI CNTLS ;CONTROL-S? 
GOD8 CB 213 RNZ ;NO, IGNORE IT 
6O8D9 CDE288 c 214 WAIT4Q: CALL CI ;YES,WAIT FOR A CONTROL-Q 
@ODC FE]] 215 CPI CNTLOQ ; 
BODE C2D99@ C 216 JINZ WAIT4Q ; 
O@0E1 C9 217 RET ;GOT IT,RETURN 
LOC OBJ SEQ SOURCE STATEMENT 
218 ; 
219 ; CI--ENTER CHARACTER FROM TERMINAL 
228 ; 
G@@E2 DBED D2) 2CYs IN cstTs ;GET STATUS BYTE 
OQGE4 E602 222 ANI RXRDY ;CHARACTER AVAILABLE 
AGE6 CAE2R2 C 223 IZ on ;NO, LOOP 
QGE9 DBEC 224 IN CDATA ;READY,GET CHARACTER 
@GEB E67F 225 ANI @7FH ;STRIP OFF PARITY 
AGED CY 226 RET 
227 ; 
228 ; CO--OUTPUT CHARACTER IN C REGISTER TO TERMINAL 
229 ; ae 
(GEE DBED 23f CO IN csTs ;GET STATUS BYTE 
@OF@ E6Al 231 ANI TXRDY ;TRANSMITTER READY? 
OGOF2 CAEES?A C 232 IZ co ;NO, LOOP 
QOFS 79 233 MOV A, ;YES,MOVE CHARACTER TO ACC. 
Q“F6 D3EC 234 OUT CDATA ;SEND TO TERMINAL 
QGF8 C9 235 RET 
236 ; 
237 ; PRTBUF--PRINTS CURRENT BUFFER (CONTROL-R) 
238 ; 
239 PRTBUF: 
G@F9 #ESD 24e MVI C,CR ;ECHO CRLF 
OAFB CDB4G@ c 241 CALL ECHO i . 
OOFE E5 — 242 PUSH H ;SAVE CURRENT BUFFER POINTER 
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AGFEF 2A8 BPA D 243 LHLD BUFPTR ;GET POINTER TO BEGINNING 
8102 D5 244 PUSH D ;SAVE CURRENT COUNTERS 
245 PRLOOP: 
@163 15 246 DCR D ;DECREMENT COUNTER 
(104 FA@FO1 Cc 247 JM PREXIT ;NO MORE CHARACTERS IN BUFFER 
G17 4E 248 MOV C,M 7;GET CHARACTER 
G@188 CDB406 C 249 CALL ECHO ;ECHO IT 
B1¢B 23 258 INX H ; INCREMENT POINTER 
G1HC C3#381 C 251 JMP PRLOOP ;LOOP UNTIL ALL CHARS OUTPUT 
252 PREXIT: 
@10F Dl 253 POP D RESTORE COUNTERS 
0110 El 254 POP H ;RESTORE POINTER 
G111 €33980 C 255 JMP GETCHR ;GET NEW CHARACTER 
256 END 
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ISIS-II FORTRAN-886 


OBJECT 


COMPILER INVOKED BY: 
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COMPILATION OF PROGRAM UNIT MAINLN 
MODULE PLACED IN :F]:MAINLN. OBJ 
FORT8@ :F]:MAINLN.FRT DEBUG DATE(1@/12/78) PAGEWIDTH(78 


SUBROUTINE MAINLN 


©) 


2 IMPLICIT LOGICAL (A-Z) 
e 
C-- MAINLINE ROUTINE FOR TEST STAND SOFTWARE. COMMAND LINE IS 
C-- SEARCHED FOR KEYLETTER AND APPROPRIATE ROUTINE IS CALLED. 
C-- ALL UNUSED LETTERS TRAP TO ERROR ROUTINE. 
3) 
C 
3 CHARACTER LINBUF(8@)*1,IMAGE*8Q 
4 INTEGER INDEX*2,CARRET*1,KEYLTR*1,ERRFLG* 2, DUMMY * 2 
5 COMMON /LINE/ LINBUF,INDEX,CARRET 
6 EQUIVALENCE (LINBUF, IMAGE) 
7 DATA CARRET /13/ 
Cc 
C-- INITIALIZE SYSTEM 
C 
8 DUMMY=P 
9 CALL FQFSET (DUMMY, DUMMY ) 
C 
C-- WRITE BANNER 
C 
10 1 WRITE (IMAGE, 14, IOSTAT=ERRFLG, ERR=999) CARRET 


FORMAT('TEST STAND V@.0',A) 


ll 1e 
C 
C-- OUTPUT BUFFER 


C 
12 CALL BUFOUT (IMAGE) 
C 
C-- INITIALIZE INDEX POINTER TO START OF LINBUF 
C 


INDEX=1 


13 20 
Cc 
C-- PROMPT OPERATOR 


C 
14 WRITE (IMAGE, 24, IOSTAT=ERRFLG, ERR=999) CARRET 
15 38 FORMAT ('COMMAND?',A) 
4 CALL BUFOUT (IMAGE) 
C 
C-- GET COMMAND LINE 
Cc 
Ly, CALL BUFIN(IMAGE) 
Cc 
C-- POSITION INDEX TO FIRST NON-BLANK CHARACTER 


Se 


21 
22 


23 
(kK). O P Q R S T U Vv W xX Y Z 


C 
CALL DBLANK 
C 
C-- CONVERT KEYLETTER TO NORMALIZED INTEGER VALUE IE. ‘A'=1] 
KEYLTR=ICHAR (LINBUF (INDEX) )-#40H 
INDEX=INDEX+1 


C-- CHECK FOR INVALID CHARACTERS 
Cc 


IF(KEYLTR.GE.1) THEN 
IF(KEYLTR.LE.41]AH) THEN 
Cc 
C-- IF VALID CHARACTER JUMP TO PROPER HANDLING ROUTINE 
C 
Cc A B C D E F ‘G H I J K L ™M N 
GOTO (380,102,168, 307,100,180,140,100,160,107,18?0,102,30%,105, 


C190,18@,18%8,100,308,200,16F,19¢,1€C,128,19@,198) KEYLTR 


2-55 


1 


) 


AFN-01931A 


24 - ENDIF. 


25 . > ENDIF» 
C a 
C-- IF INVALID OUTPUT ERROR AND GET NEW LINE 

26 WRITE (IMAGE, 40, IOSTAT=ERRFLG, ERR=999) CARRET 

27 46  FORMAT('INVALID KEYLTR',A). 

28 ‘CALL BUFOUT(IMAGE) 

- 29. GOTO 28 i : 

Cc 
C-- CONTROL BRANCHES TO ONE OF THESE BASED ON KEYLETTER 
Cc oo 
Cc. : ; ; ein 
C-- STATEMENT LINE 10@ IS USED TO TRAP ALL KEYLETTERS NOT USED 
G 

30 10@ WRITE (IMAGE,110,IOSTAT=ERRFLG, ERR=999) CARRET 

31 118 FORMAT('NO SUCH TEST',A) 

32 CALL BUFOUT (IMAGE) 

33 GOTO 29 
Cc 
C-- TRANSITION TEST 
eC 


34 200 CALL TRANST 
35 GOTO 28 
Cc 


C-- CALCULATOR MODE 


Cc 
36 38@ CALL MATH 
37 GOTO 26 
Cc 
C-- ERROR HANDLER 
C 
38 999 CALL ERROR (ERRFLG) 
39 GoTO 1 
40 END 
ISIS-II FORTRAN-88 COMPILATION OF PROGRAM UNIT DBLANK 


OBJECT MODULE PLACED IN :F]:DBLANK. OBJ 
COMPILER INVOKED BY: FORT&@ :F1:DBLANK.FRT DEBUG DATE(1#/12/78) PAGEWIDTH (78) 


a (m) SUBROUTINE DBLANK 
2 IMPLICIT LOGICAL (A-Z) 


C 
C-- POSITIONS INDEX TO NEXT NON-BLANK CHARACTER IN LINBUF 
Cc . 

3 INTEGER INDEX*2,CARRET*1,ERRFLG*2 

4 CHARACTER LINBUF (80) *1,IMAGE*8@,ENDLIN*1 

5 EQUIVALENCE (LINBUE,IMAGE) , (ENDLIN, CARRET) 

6 COMMON /LINE/ LINBUF, INDEX,CARRET 
C 

7 1 IF (LINBUF (INDEX).EQ.ENDLIN) GOTO 2 

8 IF (LINBUF (INDEX).NE.' ') RETURN 

9 INDEX=INDEX+] 

19 IF(INDEX.LE.72) GOTO 1 
C a + , ‘ 
C-- IF END OF LINE ASK FOR MORE PARAMETERS 
6 ; 

ll 2 WRITE (IMAGE, 3, IOSTAT=ERRFLG, ERR=999) CARRET 

12 3 FORMAT('MISSING PARAMETER,PLEASE ENTER',A) 

13 CALL BUFOUT (IMAGE) 

14 CALL BUFIN (IMAGE) 

15 INDEX=1 : 

16 GOTO 1 
C 
C-- ERROR HANDLER 
c | 

17 999 CALL ERROR (ERRFLG) 

18 RETURN 

19 END 

ISIS-II FORTRAN-88 COMPILATION OF PROGRAM UNIT ERROR 


OBJECT MODULE PLACED IN :F]: ERROR. OBJ 
COMPILER INVOKED BY: FORT&@ :F1:ERROR.FRT DEBUG DATE(1@/12/78) PAGEWIDTH (78) 


1 (N) SUBROUTINE ERROR (ERRNUM) 
2 IMPLICIT LOGICAL (A-2Z) 

C 

C-- OUTPUT: ERROR MESSAGE 

Cc . 
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3 CHARACTER IMAGE*&¢@,LINBUF(8@) *1 
4 INTEGER ERRNUM*2,INDEX*2,CARRET* 1 
> EQUIVALENCE (LINBUF, IMAGE) 


6 CCMMON /LINE/ LINBUF,INDEX,CARRET 
C 
7 WRITE (IMAGE,160) ERRNUM,CARRET 
8 1¢ FORMAT ('***ERROR*** #',14,A) 
sy) CALL BUFOUT (IMAGE) 
1¢ RETURN 
dey END 
ISIS-II FORTRAN-8f COMPILATION OF PROGRAM UNTT MATH 


OBJECT MODULE PLACED I[N :F]:MATH. OBJ 
COMPILER [INVOKED BY: FORTR@ :F]:MATH.FRT DEBUG DATE (1/12/78) PAGEWIDTH(78) 


] (CO) SUBROUTINE MATH 
2 IMPLICIT LOGICAL (A-2Z) 
C-~- TMPLEMENTS CALCULATOR MODE 


INTEGER INDEX*2,CARRET*] ,ERRFLG*2 
CHARACTER LINBUF(8@)*1,IMAGE*8@,COMMND*1,SYMBOL* 1 


REAL OP],OP2,RESULT 
EQUIVALENCE (LINBUF, IMAGE) 
COMMON /LINE/ LINBUF, INDEX, CARRET 


SDS D W 


C-- RESCAN KEYLETTER TO DETERMINE OPERATION 
8 INDEX=INDEX-1 
9 COMMND=LINBUF (INDEX) 
INDEX=J NDEX+] 
C-- MOVE INDEX TO FIRST OPERAND 
11 CALL DBLANK 
C-- GET IT IN 
CALL CONVRT (OP1) 


1? 
Cc 
C-- REPEAT FOR SECOND OPERAND 


12 CALL DBLANK 
14 CALL CONVRT(OP2) 


C-- PERFORM OPERATION 


eC 
}5 IF (COMMND. EQ. 'M') THEN 
14 RESULT=OP1*OP? 
17 SYMBOL='*! 
18 eloune mh 
19 ENDIE 
é 
20. TF(COMMND.FQ.'D') THEN 
2 RESULT=OP] /OP2 
22 SYMBOL='/! 
23 COTO 71 
24 ENDIF 
C 
25 TF(COMMND.EC.'A') THEN 
26 RESULT=O0P1+0P2 
27 SYMBOL='+! 
28 Core: 14 
29 ENDIF 
€ 
20 IF(COMMND.FQ.'S') THEN 
31 RESULT=OP1-OP2 
32 SYMBOL='-'! 
33 GOTO ll 
34 ENDIF 
fe 
C-- OUTPUT RESULTS 
Cc 
35 ll WRITE (IMAGE,12,IOSTAT=ERRFLG, ERR=999) OP1,SYMECL,OP2,RESULT, 
1CARRET 
36 12. FORMAT(F18.5,1X,A,1X,F1&.5,1X,'=',1X,F1&.5,A) 
37 CALL BUFOUT (IMAGE) 
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38 RETURN 
Cc 
C-- ERROR HANDLER 
C : 
39 999 CALL ERROR (ERRFLG) oh 
49 _ RETURN 
41 END 
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ISIS-II FORTRAN-€@ COMPILATION OF PROGRAM UNIT CONVRT 


OBJECT MODULE PLACED IN :F1:CONVRT. OBJ ; 
COMPILER INVOKED BY: FORT8(@ :F1:CONVRT.FRT DEBUG DATE(18/12/78) PAGEWIDTH (78) 


SD SW 


rPewoew 


tos te 


12 
1.3 
14 
15 
16 
17 
18 
19 
20 


21 
22 
23 


®) 


C 
Ca 
C 


SUBROUTINE CONVRT (VALUE) 
IMPLICIT LOGICAL(A-Z) 


INPUTS NEXT PARAMETER IN LINBUF 


INTEGER I*#1,INDEX*2,TMPIND*1,CARRET*1,ERRFLG*2 

REAL VALUE 

CHARACTER LINBUF(8&@)*1,TMPBUF(20)*1,BUFFER*20,ENDLIN*®1 
EQUIVALENCE (TMPBUF,BUFFER) , (ENDLIN,CARRET) 

COMMON /LINE/ LINBUF, INDEX, CARRET 


INITIALIZE 
DO 2] I=1,19 
TMPBUF(I)=" ° 
TMPBUF (29) =ENDLIN 
TMPIND=] 


C-- FILL BUFFER UNTIL COMMA OR ENDLINE ENCOUNTERED 


TMPBUF (TMPIND) =LINBUF (INDEX) 
INDEX=INDEX+1 

TMPIND=TMPIND+] 

IF (LINBUF(INDEX).EQ.',') THEN 
INDEX=INDEX+1] 

GOTO 23 

ENDIF 

IF (LINBUF (INDEX) .EQ.ENDLIN) GOTO 23 
GOTO 22 


C 
C-- READ UNDER FORMAT CONTROL 
C 


READ (BUFFER, 24, IOSTAT=ERRFLG, ERR=999) VALUE 
FORMAT (F19.5) 
RETURN 


Cc 
C-- ERROR HANDLER 
C 
24 999 CALL FRROR(ERRFLG) 
25 RETURN , 
26 END 
ISIS-II FORTRAN-8@ COMPILATION OF PROGRAM UNIT TRANST 


OBJECT MODULE PLACED IN :F1:TRANST. OBJ 


COMPILER INVOKED BY: 


Nor 


Cc 


SUBROUTINE TRANST 
IMPLICIT LOGICAL (A-2Z) 


C-- PERFORM TRANSITION TESTING 


C 


C 


Cc 


Cc 


REAL START,STOP,STEP, TOL, TEMP, VOLTAG, VCC (24), 
1LOWLVL(2@) ,LOTOHI (20) ,HILVL(2@) ,HITOLO (28) 


INTEGER CARRET*1],ITEMP*2,TSTINP*2,SAMPLE*2, | 
1LSTSAM* 2, DELTA* 2, ERRFLG*2,PNTCNT*1,INDEX*2,I*1 


CHARACTER LINBUF (80) *]1,IMAGE*8@, TEST (2@) *5 
EQUIVALENCE (LINBUF, IMAGE) 


COMMON /LINE/ LINBUF, INDEX, CARRET 


C-- INITIALIZE 


Cc 
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8 DO 5, I=1,2¢ 


9 =) TEST (1I)="PASSED' 

18 TSTINP=6 

11 PNTCNT=1] 
Cc 
C-~~- SCAN COMMAND TAIL FOR PARAMETERS 
Cc 
Cc vcc START STOP STEP TOLERANCE 
Cc 

12 CALL DBLANK 

13 CALL CONVRT (START) 

14 CALL DBLANK 

15 CALL CONVRT (STOP) 

16 CALL DBLANK 

17 CALL CONVRT (STEP) 

18 CALL DBLANK 

19 CALL CONVRT (TOL) 
C 


C-- IF (STOP-START)/STEP YIELDS MORE THAN 20 STEPS 
C-- OUTPUT MESSAGE AND RETURN 


ec 
20 IF(IFIX((STOP-START)/STEP).GT.20) THEN 
21 WRITE.(IMAGE,1@, LOSTAT=ERRFLG, ERR=999) CARRET 
22 1a FORMAT ('TOO MANY POINTS',A) 
23 CALL BUFOUT (IMAGE) 
24 RETURN 
25 ENDIF 
c 
C-- GET TEMPERATURE AND LINEARIZE 
@ 
26 CALL ADCIN(ITEMP,@) 


a7 (U) TEMP=98.63*ALOG (FLOAT (ITEMP) )+12.56 


C 
C~- CUTPUT HEADER 
C 
28 WRITE (IMAGE,20, IOSTAT=ERRFLG, ERR=999) TOL, TEMP, CARRET,CARRET 
29 2” FORMAT('TRANSITION TEST TOLERANCE=',F5.1, 
J'$ AMBIENT TEMPERATURE = ',FA#.2,' DEGREES C',A,A) 
3@ CALL BUFOUT (IMAGE) 
3] WRITE (IMAGE, 30, IOSTAT=ERRELG, ERR=999) CARRET,CARRET 
32 30 FORMAT (' vcc HIGH TRANS LOW TRANS HIGH LOW TEST', 
1A,A) 
33 CALL BUFOUT (IMAGE) 


Cc 
C-- BEGIN TEST; OUTPUT STARTING VCC VALUE 
Cc 


34 VOLTAC=START 


35 4n VCC (PNTCNT) =VOLTAG 
36 CALL DACOUT(IFIX (VOLTAG*4?9.6) ,@) 
€ 


C-- OUTPUT ZERO VOLTS TO TEST INPUT 


x 
”(v) CALL DACOUT(TSTINP, 1) 


c 
C-- GET ONE SAMPLE 


C 
38 CALL ADCIN(SAMPLE,1) 
e 
C-- MAKE IT THE LAST SAMPLE AND ALSO STORE IT 
Cc 
39 LSTSAM=SAMPLE 
4p LOWLVL (PNTCNT) =FLOAT (SAMPLE) *409. 6 
Cc 
C-- RECIN LOOP LOOKING FOR LOW TO HIGH TRANSITION 
Cc 
41 5¢ TSTINP=TSTINP#+] 
42 CALL DACOUT(TSTINP,1) 
Cc 
C-- GET SAMPLE 
CG 
42 CALL ADCIN(SAMPLE,]) 
44 DELTA=SAMPLE-LSTSAM 
Cc 
C-- SEE IF TRANSITION;DELTA .GT. 2.2 VOLTS 
c 
4s IF(DELTA.LT.9@1) THEN 
46 LSTSAM=SAMPLE 
Cc 


C-- NO TRANSITION; IF TSTINP NOW UP TO 5.5V AND-NO TRANSITION 
C-- QUTPUT MESSAGE INDICATING DEAD PART ANI RETURN 


Qn 
Y 


47 IF(TSTINP.GE.2251) THEN 
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53 
54 


55 


56 


57 


58 


60 


61 
62 


63 
64 


65 
66 


67 
68 


69 


77 


FORMAT ('DEAD PART, NO TRANSITION',A) 
CALL BUFOUT (IMAGE) 

RETURN 

ENDIF 


(W) WRITE (IMAGE,45@, IOSTAT=ERRFLG,ERR#999) CARRET 
68 


C-- CONTINUE LOOP 


C 
GOTO 58° 
ENDIF 
C 
C-- TRANSITION; ASSIGN ARRAY ELEMENT 
é 
LOTOHI (PNTCNT) =FLOAT (TSTINP) /469.6 
C 
C-- CHECK TOLERANCE 
Cc 
IF ((LOTOHI (PNTCNT) .GE. (.8-(TOL/10@0.*.8))).AND. 
1 (LOTOHI (PNTCNT) .LE.(.8+(TOL/10@.*.8)))) GOTO 7¢ 
Cc 
C-- TEST FAILED 
Cc 
TEST (PNTCNT)='FAILED'! 
Cc 
C-- BEGIN HIGH TO LOW TEST 
Cc 
Cc 
C-- OUTPUT 5.98 VOLTS 
Cc 
70 TSTINP=2048 
CALL DACOUT (TSTINP,1) 
c 
C-- GET SAMPLE 
C 
CALL ADCIN (SAMPLE) 
Cc 
C-- MAKE IT LAST SAMPLE AND ALSO STORE IT 
C ; 
LSTSAM=SAMPLE . 
HILVL(PNTCNT) =FLOAT (SAMPLE) *4@9.6 , 
C 
C-- BEGIN LOOP LOOKING FOR HIGH TO LOW TRANSITION 
Cc r 
80 TSTINP=TSTINP-1 
CALL DACOUT(TSTINP,1) 
Cc 
C-- GET SAMPLE. 
@ 
CALL ADCIN(SAMPLE,1) 
DELTA=LSTSAM-SAMPLE 
C . 
C-- SEE IF TRANSITION; DELTA .GT. 2.2 VOLTS 
C : 
IF (DELTA.LT.9@1) THEN 
LSTSAM=SAMPLE 
Cc 
C-- NO TRANSITION; CHECK TO SEE IF VOLTAGE DOWN TO ZERO 
c 
IF(TSTINP.LE.®) THEN 
Cc 
C-- YES; OUTPUT DEAD PART MESSAGE 
@ 
WRITE (IMAGE, 60, IOSTAT=ERRFLG, ERR=999.) CARKET 
CALL BUFOUT (IMAGE) 
RETURN 
ENDIF 
eG 
C~- CONTINUE LOOP 
Cc 
GOTO eF 
ENDIF 


C 
C-- TRANSITION; ASSIGN ARRAY ELEMENT 
Cc 


HITOLO(PNTCNT) =FLOAT (TSTINP) *469.6 


@ 
C-- CHECK TOLERANCE 
Cc ¢ 
IF ( (HITOLO(PNTCNT) .GE. (3.5-(TOL/1@6@.*3.5))).AND. 
1 (HITOLO(PNTCNT) «LE. (2.5+(TOL/108.*3.5)))),. GOTO 98 
C : rr . . 
C-- TEST FAILED 
‘c 
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78 TEST (PNTCNT) ='FAILED' 


Cc 
C-~ INCREMENT VCC AND IF NOT .GT. STOP CONTINUE 
c 

79 90 VOLTAG=VOLTAG+STEP 

8a IF (VOLTAG.LE.STOP) THEN 

8] PNTCNT=PNTCNT+]1 

a2 TSTINP=90 

83 GOTO 4¢@ 

BA ENDIF 
Cc 
C-- TEST COMPLETE; QUTPUT RESULTS 
eG 

85 DO 11¢,I=1,PNTCNT 

86 WRITE (IMAGE, 10€, IOSTAT=ERRFLG, ERR=999) VCC(I), 

1LOTOHI (I) ,HITOLO(I) ,HILVL(I),LOWLVL(1I),TEST(1I),CARRET 

87 1F@ FORMAT (3X,F5.2,3X,F6.2,6X,F6.2,3X,F6.2,1X,F6.2,2X,6A,A) 

gg 110 CALL BUFOUT (IMAGE) 

89 RETURN 
C 
C-- ERROR HANDLER 
Cc 

oA 999 CALL ERROR (ERRFLG) 

9] RETURN 

92 END 
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ISIS-II FORTRAN-82 COMPILATION OF PROGRAM UNIT ADCIN 


OBJECT MODULE PLACED IN :F1:ADCIN.CBJ 
COMPILER INVOKED BY: FORT&8@ :F1:ADCIN.FRT DEBUG DATE(1@/12/78) PAGEWIDTH (78) 


1 (x) SUBROUTINE ADCIN(VALUE,CHAN) 


C-- ROUTINE TO INPUT SINGLE VALUE FROM A/D CONVERTER CHANNEL 
C-- GIVEN AND RETURN IT IN VALUE FIELD. 
Cc 


2 INTEGER*? VALUE 
2 INTEGER*1 CHAN 
4 S$ INCLUDE (: F]:ADCDAC.DEC) 
= C 
= (C-- DEFINITIONS OF TSBC 732 REGISTERS 
= C 
= C 
= C-- COMMAND STATUS REGISTER 
c 
5 INTEGER*1 CMDSTS 


Cc 
C-- MUX ADDRESS REGISTER 
Cc 


6 INTEGER*1 MUXADR 
Hi es LAST CHANNEL REGISTER 
7 = . INTEGER*] LSTCHN 
Bs CLEAR INTERRUPT COMMAND WORD 
Boe s INTEGER*1 CLRINT 
a bes ADC DATA REGISTER 
9 = : INTEGER*2 ADCDAT 
: - DAC @ DATA REGISTER 
la = F INTEGER*2 DAC? 
: as DAC 1 DATA REGISTER 
ll = : INTEGER*2 DAC] 
: ae SET UP COMMON BLOCK 
12 = COMMON /ADC/ CMDS'TS,MUXADR, LSTCHN, CLRINT,ADCDAT, DAC@,DAC1 
a SET UP CHANNEL ADDRESS | | 
13 “ MUXADR=CHAN 
ete START CONVERSION 
C 


14 CMDSTS=#1H 
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C 
C-- WAIT FOR END OF CONVERSION 


C : 

15 ] LF ((CMDSTS.AND. #8¢H) .NE.4#8@H) GOTO 1 
Z ed 
C=-= GET DATA IN 
Cc 

16 VALUE=ADCDAT 
é 
C-- RIGHT JUSTIFY AND CONVERT TO COUNTS 
Cc 

17 VALUE=VALUE/16 . 

18 IF(VALUE.LT.@) VALUE=VALUE+409641 

19 RETURN 

26 END 

ISIS-II FORTRAN-82 COMPILATION OF PROGRAM UNIT DACOUT 


OBJECT MODULE PLACED IN :F1:DACOUT.OBJ 
COMPILER INVOKED BY: FORT8@ :F1l:DACOUT.FRT DEBUG DATE(1#/12/78) PAGEWIDTH(78) 


J (Y) SUBROUTINE DACOUT (VALUE, CHAN) 


c 
C-- OUTPUTS VALUE TO D/A CONVERTER 
C 
2 INTEGER*2 VALUE,CHAN 
3 ¢ INCLUDE (:F1:ADCDAC. DEC) 
= C 
= (C-- DEFINITIONS OF ISBC 732 REGISTERS 
= C 
= Cc 
= C-- COMMAND STATUS REGISTER 
= C 
4 = INTEGER*1 CMDSTS 
= C 
= C-- MUX ADDRESS REGISTER 
= C 
5 = INTEGER*1 MUXADR 
= C 
= C-- LAST CHANNEL REGISTER 
= C 
5 = INTEGER*1 LSTCHN 
= C 
= C-- CLEAR INTERRUPT COMMAND WORD 
= C 
7 = INTEGER*] CLRINT 
= C 
= C-- ADC DATA REGISTER 
= Cc 
8 = INTEGER*2 ADCDAT 
= C 
= C-- DAC @ DATA REGISTER 
= Cc 
9 = INTEGER*2 DACQ@ 
= C 
= C-- DAC 1 DATA REGISTER 
= C 
1g = INTEGER*2 DAC] 
= C 
= C-- SET UP COMMON BLOCK 
= Cc 
ll = COMMON /ADC/ CMDSTS ,MUXADR, LSTCHN, CLRINT,ADCDAT, DAC ,DAC1 
Cc 
C-- OUTPUT VALUE TO PROPER CHANNEL 
C-- AFTER SHIFTING INTO HIGH ORDER 12 BITS 
c 
12 IF (VALUE.LT.@) VALUE=VALUE+49964+1 
13 VALUE=VALUE* 16 
14 IF (CHAN. EQ.@) DAC@=VALUE 
15 IF(CHAN.EQ.1) DAC1=VALUE 
16 RETURN 
17 END 
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APPENDIX B 
CODE LISTINGS 
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ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE SEMAPHORES 
OBJECT MODULE PLACED IN :F1:SEMMOD. OBJ 
COMPILER INVOKED BY: plm8@ :F1:SEMMOD.plm DEBUG DATE(1@/12/78) PAGEWIDTH(78) 


1 SEMAPHORES : 
DO; 
J BRR RRR IIR RIKI RII RK II IK RR RI KTR III HTK R IKK RRR EI KER EKER 
Contains LOCK and UNLOCK: procedures for 
manipulating semaphores. Called by FORTRAN 
routines with one parameter; the address of 
the index of the semaphore to be operated on. 
HHH III KIKI IKI IKK IIH K IKI KKK KEK EEK KERR KEKE KEE KK / 
Snolist 
17 1 DECLARE (stslok,setlok,dsklok) (186) BYTE PUBLIC; 
18 1 DECLARE semaphore(3) ADDRESS PUBLIC DATA ( 
-stslok, 
-setlok, 
~-dsklok); 
19 1 DECLARE token (3) STRUCTURE ( 
link ADDRESS, 
length ADDRESS, 
type ADDRESS) PUBLIC; 
2@ 1 LOCK: PROCEDURE(semaSnumberSptr) REENTRANT PUBLIC; 
21 2 DECLARE semaSnumberSptr ADDRESS; 
22 2 DECLARE semaSnumber BASED sema$numberSptr BYTE; 
23°--2 DECLARE msg$ptr ADDRESS; 
24 2 msg$ptr=ROWAIT (semaphore (semaSnumber ) ,@); 
25 2 RETURN; 
26 2 END; 
27 1 UNLOCK: PROCEDURE (semaSnumberSptr) REENTRANT PUBLIC; 
28 2 DECLARE sema$number$ptr ADDRESS; 
29 2 DECLARE semaSnumber BASED sema$numberSptr BYTE; 
30 2 CALL ROSEND (semaphore (semaSnumber),.token(semaSnumber) ); 
31 2 RETURN; 
32 2 END; 
33 l END SEMAPHORES; 
ISIS-II FORTRAN-89 COMPILATION OF PROGRAM UNIT STSINP 


OBJECT MODULE PLACED IN :F1:STSMOD.OBJ 
INVOKED BY: FORT8@ :F1:STSMOD.FRT DEBUG DATE(16/12/78) PAGEWIDTH(78) 


COMPILER 


DAH U & Ww 


SUBROUTINE STSINP 
IMPLICIT LOGICAL (A-Z) 


TASK CODE FOR STATUS INPUT TASK. UPDATES STATUS COMMON 
BLOCK WITH ANALOG AND DIGITAL DATA VALUES. ALSO DOES 
ANALOG COUNT TO ENGINEERING UNIT CONVERSIONS. 

CHARACTER SMPLBF*22,CLOCK*12 

INTEGER*2 SAMPLS (11) , DUMMY 

REAL ANDATA (11) 

EQUIVALENCE (SMPLBF,SAMPLS) 

INTEGER*1 DIGDAT,I 

COMMON /STATUS/ ANDATA,DIGDAT,CLOCK 
INITIALIZE FLOATING POINT LIBRARIES 


DUMMY=86 
CALL FQFSET (DUMMY, DUMMY ) 


CALL INITIALIZATION ROUTINE 
CALL INITIO 

CALL ROUTINE TO INPUT SAMPLES 
CALL SMPLIN (SMPLBF) 


SHIFT SAMPLS TO RIGHT JUSTIFY 
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DO 5@ I=1,11 
SAMPLS (1) =SAMPLS (I) /16 
58 IF(SAMPLS(I).LT.@) SAMPLS (I)=SAMPLS (1) +4096+1 


Cc 
C-- WAIT FOR ACCESS TO STATUS COMMON BLOCK FOR UPDATE 
C-- THEN CONVERT SAMPLES TO ENGINEERING UNITS AND STORE 


Cc 


CALL LOCK (@) 
ANDATA(1)=FLOAT (SAMPLS (1) ) 

ANDATA (2) =ALOG1@ (FLOAT (SAMPLS) *2. 34)-355. 98 
ANDATA (3) =ALOG1@ (FLOAT (SAMPLS (3) /13.9)-21.523 
ANDATA (4) =13, 23*FLOAT (SAMPLS (4) )-20.78 
ANDATA (5) =FLOAT (SAMPLS (5) ) 

ANDATA (6) =FLOAT (SAMPLS (6) ) /14. 225 

ANDATA (7) =FLOAT (SAMPLS (7) ) 

ANDATA (8) =ALOG (FLOAT (SAMPLS (8) /23.98) +235. 98 
ANDATA (9) =FLOAT (SAMPLS (9) ) 

ANDATA (1@) =FLOAT (SAMPLS (19) ) 
ANDATA(11)=(FLOAT(SAMPLS(1]))-119. 34)/5. 7340 
CALL INPUT (#@E8H,DIGDAT) 


H) 


Cc 
C-- RELEASE LOCK ON STATUS COMMON BLOCK 


CALL UNLOCK (@) 
C 
C-- DELAY FOR 1 SECOND THEN SCAN AGAIN 


¢ 
1@) CALL WAIT 
€ 


C-~-— LOOP BACK 


C 
31 GOTO 14 
32 END 
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ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE ANALOGIOMOD 
OBJECT MODULE PLACED IN :Fl:aiomod. OBJ 
COMPILER INVOKED BY: plm&@@ :Fl:aiomod.plm DEBUG DATE(1@/12/78) PAGEWIDTH(78) 


24 
25 


ANALOGSIOSMOD: 
DO; 


[BR ER RRR KKK IKKE KI IK RK KKK IKK KEK KEKE KEKE EKEKEKEKEKKERKEKKEKE 


Inputs analog samples into buffer picvaded as 
calling parameter. 


RRR RRR IK IRR IIIA / 
Snolist 


G) DECLARE ANSRESP (18) BYTE PUBLIC; 
DECLARE ANALOGSREQUESTSMESSAGE aiS$msg; 


1 INITIO: PROCEDURE PUBLIC; 


/* initializes mesage to be used for analog samples */ 


2 ANALOGSREQUESTSMESSAGE. length=size (ANALOGSREQUESTSMESSAGE) ; 
2 | ANALOGSREQUESTSMESSAGE.type=AISQS; 

2(K) ANALOGSREQUESTSMESSAGE.responseSexchange=.ANSRESP; 

2 ANALOGSREQUESTSMESSAGE ..baseSptr=@FFFQ@H; 

2 ANALOGS REQUESTSMESSAGE. channel $gain=6; 

2 RETURN; : 

2 END; /* of INITSIO */ 


d SMPLSIN: PROCEDURE (sampleSbufferSptr,bufSsize) PUBLIC; 


/* inputs buf$size/2 analog word samples */ 


2 DECLARE (sample$bufferSptr,buf$size,dummy) ADDRESS; 

2 DECLARE sampleSbuffer BASED sampleSbufferS$ptr (1) BYTE; 
2 ANALOG $REQUESTSMESSAGE..array$ptr=sample$bufferSptr; 
2 ANALOGS REQUESTSMESSAGE.count=buf$size/2; 


2 CALL RQSEND(.RQAIEX, .ANALOGSREQUESTSMESSAGE) ; 
dummy =RQWAIT (.ANSRESP, @); 
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RETURN; 
END; /* of SMPLSIN */ 


END ANALOGSIOSMOD; 


COMPILATION OF PROGRAM ‘UNIT SCAN 


OBJECT MODULE PLACED IN :F1:SCANMD. OBJ 


COMPILER INVOKED BY: 


WO AW & Wh 


34 


35 
36 


37 


38 


Huon toa tt 


SUBROUTINE SCAN 
Cc 


C-- CODE FOR SCAN TASK THAT COMPARES STATUS VALUES WITH 
C-- SETPOINTS AND SETS OPERATOR ALARMS ACCORDINGLY. ALSO 
C-- LOGS DISK RECORD OF STATUS WHEN MINSUP FLAG IS TRUE. 


Cc 

SINCLUDE (: Fl: EQUIV. DEC) 

CHARACTER BUFFER*57, PARAMS (57) *1 

REAL PH, VOLUME, TEMP, DISOXY, TOTCAR, ORGCAR 
REAL SUSSOL, PHOSFT, INFLOW, EFLFLO,TURBID 
INTEGER*] DIGDAT 

INTEGER*2 MONTH,DAY,YEAR,HOUR,MINUTE,SECOND 
EQUIVALENCE (PARAMS,BUFFER) 

EQUIVALENCE (PARAMS, PH) 

EQUIVALENCE (PARAMS (5) , VOLUME) 
EQUIVALENCE (PARAMS (9) , TEMP) 
EQUIVALENCE (PARAMS (13) ,DISOXY) 
EQUIVALENCE (PARAMS (17) ,TOTCAR) 
EQUIVALENCE (PARAMS (21) ,ORGCAR) 
EQUIVALENCE (PARAMS (25) ,SUSSOL) 
EQUIVALENCE (PARAMS (29) , PHOSFT) 
EQUIVALENCE (PARAMS (33) , INFLOW) 
EQUIVALENCE (PARAMS (37) ,EFLFLO) 
EQUIVALENCE (PARAMS (41) ,TURBID) 
EQUIVALENCE (PARAMS (45) ,DIGDAT) 
EQUIVALENCE (PARAMS (46) ,MONTH) 
EQUIVALENCE (PARAMS (48) , DAY) 
EQUIVALENCE (PARAMS (5@) , YEAR) 
EQUIVALENCE (PARAMS (52) ,HOUR) 
EQUIVALENCE (PARAMS (54) ,MINUTE) 
EQUIVALENCE (PARAMS (56) ,SECOND) 
INTEGER* 2 ERRFLG, RECNO,DUMMY 

REAL SETSOL,SETCAR,SETPHS, SETTRB 
INTEGER*1 MIN5UP 
COMMON /MINS/ MINSUP 

COMMON /SETPNT/ SETPHS,SETSOL,SETCAR,SETTRB 
COMMON /STATUS/ BUFFER 

COMMON /LSTREC/ RECNO 


Cc 
C-- INITIALIZE RECORD COUNTER 
Cc. ; 

RECNO=1 
Cc : 
C~- INITIALIZE MATH LIBRARIES 
Cc 

’DUMMY=@ 

CALL FQFSET (DUMMY ,DUMMY ) 
Cc 


C-- WAIT FOR ACCESS TO STATUS AND SETPOINT COMMON BLOCKS 


Cc 
18 CALL LOCK (@) 


CALL LOCK(1) 
C 
C-- SCAN FOR ALARMS ONLY IF EFFLUENT PUMP IS ON 
C 


IF( (DIGDAT.AND. #@4H) .EQ.#@4H) THEN 
IF (PHOSFT.GT.SETPHS) THEN 
CALL OUTPUT (#@EBH,#@1H). 
ELSE 

CALL OUTPUT (#@EBH, #@0H) 
ENDIF 

IF(SUSSOL.GT.SETSOL) THEN. 
‘CALL OUTPUT (#@EBH,#03H) 
ELSE 
CALL OUTPUT (#@EBH, #@2H) 
ENDIF - oes 
IF (TOTCAR.GT.SETCAR) THEN 
CALL OUTPUT (#@EBH, #05H) 
ELSE 
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5.3 CALL OUTPUT (#8EBH, #04H) 


54 ENDIF 
55 [F(TURBID.GT.SETTRB) THEN 
56 CALL OUTPUT (#@EBH, #@7H ) 
57 ELSE 
58 CALL OUTPUT (#@EBH, #@6H) 
59 ENDIF 
6A ENDIF 
C 
C-- IF MIN5 TASK HAS SET MIN5UP LOG STATUS ON DISK 
C 
61 (0) IF (MIN5UP.NE.98) THEN 
42 MIN5UP=@ 
C 
C-- WAIT FOR ACCESS TO DISK 
C 
63 CALL LOCK (2) 
64 OPEN (3, FILE=':D@:TODAYS.RPT',STATUS='OLD', IOSTAT=ERRFLG, 


lERR=9@@@,ACCESS='DIRECT',RECL=57) 
55 (P) WRITE (3, REC=RECNO, IOSTAT=ERRFLG, ERR=9188) BUFFER 


66 RECNO=RECNO+] 
57 CLOSE (3,IOSTAT=ERRFLG, ERR=92?'0) 
58 CALL UNLOCK (2) 
69 ENDIF 
Cc 
C-- RELEASE LOCK ON STATUS AND SETPOINT COMMON BLOCKS 
Cc 
70 CALL UNLOCK (1) 
had. CALL UNLOCK (@) 
Cc 
C-- DELAY FOR 1 SECOND THEN SCAN AGAIN 
C 
72 CALL WAIT 
C 
C-- LOOP BACK 
Cc 
73 GOTO 14 
CG 


GC-- ERROR HANDLERS 


WRITE (6,9801) ERRFLG 

FORMAT (‘OPEN ERROR IN SCAN; #',14) 

GOTO ‘18 

WRITE (6,9101) ERRFLG 

FORMAT ('WRITE ERROR IN SCAN; #',14) 
GOTO 18 

WRITE (6,9261) ERRFLG 

FORMAT('CLOSE ERROR IN SCAN; #',14) 


GOTO 18 
END 
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ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE MIN5MOD 
OBJECT MODULE PLACED IN :F1:MINS5SMD.OBJ 
COMPILER INVOKED BY: plm8@ :F1l:MIN5MD.plm DEBUG DATE(1@/12/78) PAGEWIDTH (7/8) 


1 MINSSSMOD: 
DO; 


J BREE RRR KERR KEKE EERE RK KK KERR EERE KEKEEREREKRKEREREEEREKKK 


This module contains the code for TIMERS5 who 
waits for 5 minutes and sets a flag telling 
SCAN to log a report on the disk, and for 
WAIT who waits for 1 second then returns 


KKK IKK II KKK KI IKK KKK KR ERK AR KEKE KEIEK KK IEKHEKKREREEEE KE / 


Snolist 
19 1 DECLARE minS$5S$ex (180) BYTE PUBLIC; 
28 1 DECLARE min$5Sup BYTE AT (QE FEEH) ; 
24 l DECLARE timeSoutSmsg$ptr ADDRESS; 
22 1 DECLARE fiveSminuteS$delayScount LITERALLY '6880'; 
23 1 DECLARE timesSup LITERALLY '@lH'; © a: 
24 1 WAIT: PROCEDURE REENTRANT PUBLIC; 
25 2 timeSout$msg$ptr=RQWAIT (.min$5$ex, 20); 
26 2 (R RETURN; 
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END; 


TIMERS: PROCEDURE PUBLIC;.. 
minS$S5S$up=@; 


/* enter task loop */ 


DO WHILE 1; 
timeSoutSmsg$ptr= RQWAIT(. nin$5Sex, fiveSminuteSdelayScount) ; 
min$5SSup=timesSup; 
END; /* of do while 1 */ 
END; /* of procedure */ 
END; /* of module */ 


ISIS-II PL/M-8@ V3: 1 COMPILATION OF MODULE REPORT 
OBJECT MODULE PLACED IN :F]:RPTMOD.OBJ © 
COMPILER INVOKED BY: plmeo :F1:RPTMOD.plm DEBUG DATE (10/12/78) PAGEWIDTH (78) 


21 
22 
23 
24 


25 
26 
27 
28 
29 
36 
31 


32 
33 


34 


35 


36 
37 


38 
39 


468 
41 


42 
43 


45 
46 
47 


DON N 


NNN bd 


RN Ww 


REPORT: 
DO; 


JS BRR IKKE KEE IKKKEIIKREKRKEKKRKE KK KRKKKKK KERR KERR KEKKEKKKKKEKKEK KKK K 


This module contains the code for the REPORT 
task that prints formatted reports of system 
Status upon command. Commands come in from 
PRTREQ exchange with type=100 for todays. 
Status report and type = 161 for yesterday's 
status report. PRINT is the FORTRAN routine 
that does the actual work. 


PII RI RIK IHR ITI IRR IKK RIT IK IIR IK IIR RIKI RRR K KR RK / 


Snolist 


PRINT: PROCEDURE (fileSptr,nameSsize,requestS$type) EXTERNAL; 
DECLARE (fileSptr,name$size) ADDRESS; 
DECLARE requestStype BYTE; 

END PRINT; 


FOFSET: PROCEDURE(A,ERRH) EXTERNAL; 
DECLARE (A,ERRH) ADDRESS; 
END FQFSET; 


DECLARE prt$req (10) BYTE PUBLIC; 


REPORT: PROCEDURE PUBLIC; 


DECLARE todayStype LITERALLY '198'; 
DECLARE yesterdayStype LITERALLY '1@1'; 
DECLARE (ptr,dummy) ADDRESS; 
DECLARE msg BASED ptr STRUCTURE ( 
link ADDRESS, 
length ADDRESS, 
type BYTE, 
homeSexchange ADDRESS, 
responseSexchange ADDRESS) ; 
DECLARE today$fileS$name (*) BYTE DATA(':D@:TODAYS.RPT'); 
DECLARE ystday$file$name (*) BYTE DATA(':D@:YSTDAY.RPT'); 


/* initialize math handler */ 


dummy =8 ; 
CALL FOFSET(.dummy,.dummy) ; 


7* enter task loop */ 


DO WHILE 1; 
/ ptr=RQWAIT(.prtSreq,®@); 


IF msg.type=today$type THEN 


ype); 
ELSE IF msg. ‘types =yesterdayStype ‘THEN 


CALL print(. ystday$SfileSname, a a 


-type) ; 
CALL ROQOSEND(msg. responseSexchange ptr) ; 
END; /* of do while */.- es 
END; /* of task */ 
END REPORT; 
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COMPILATION OF PROGRAM UNIT HEADER 


OBJECT MODULE PLACED IN :F1:PRNTMD. OBJ 


COMPILER INVOKED BY: FORT8@ :F1:PRNTMD.FRT DEBUG DATE(16/12/78) PAGEWIDTH (78) 


ISIS-II FORTRAN-&@ 


SUBROUTINE HEADER 


CG 
C-- CALLED BY PRINT TO OUTPUT REPORT HEADER 
Cc 
WRITE (6, 200) 
20@  FORMAT(' DATE TIME PH VOLUME TEMP 


eee 2 
l1'TOTAL ORGANIC SUSPENDED PHOSPHATE INFLUENT EFFLUENT 
2'TURBID AIR DIS MIX INF‘) 
WRITE (6,281) 


201 FORMAT (44X, ‘OXYGEN CARBON CARBON SOLIDS 
1'FLOW FLOW’) 
WRITE (6, 202) 
282 FORMAT (24X,' (CU.M) (C) (MG/ML) (MG/ML) (MG/ML) 
1'(MG/ML) (MG/ML) (MG/ML) (MG/ML) $') 
RETURN 
END 


COMPILATION OF PROGRAM UNIT PRINT 


OBJECT MODULE PLACED IN :F1:PRNTMD.OBJ 


COMPILER INVOKED BY: 


ODMDAIYHDMBHWNH 


35 


Wout 


Woo dt 


Hou u ue te hoa oa 


Hoh Wb ot Wott 


Cc 
C-- SUBROUTINE PRINT CALLED BY REPORT TO GENERATE FORMATTED 
C-- REPORTS. PRINTS EITHER TODAY'S FILE OR YESTERDAY'S 
C-- DEPENDING ON FILNM INPUT VALUE. 
Cc 

SUBROUTINE PRINT(FILNM,TYPE) 

IMPLICIT LOGICAL (A-Z) 

CHARACTER*14 FILNM 

INTEGER*2 ERRFLG,RECCNT,LSTREC 

INTEGER*1 TYPE 

INTEGER*1]1 INDEX 
SINCLUDE(:F1:EQUIV.DEC) 

CHARACTER BUFFER*57, PARAMS (57) *1 

REAL PH,VOLUME, TEMP,DISOXY,TOTCAR, ORGCAR 

REAL SUSSOL,PHOSFT, INFLOW, EFLFLO,TURBID 

INTEGER*] DIGDAT 

INTEGER*2 MONTH,DAY,YEAR,HOUR,MINUTE,SECOND 


DISSOLVED 


CONC',6X, 


FORT8@ :F1:PRNTMD.FRT DEBUG DATE(1@/12/78) PAGEWIDTH (78) 


EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 
EQUIVALENCE 


(PARAMS, BUFFER) 
(PARAMS , PH) 
(PARAMS (5) , VOLUME) 
(PARAMS (9), TEMP) 
(PARAMS (13) , DISOXY) 
(PARAMS (17) , TOTCAR) 
(PARAMS (21) , ORGCAR) 
(PARAMS (25) ,SUSSOL) 
(PARAMS (29) , PHOSFT) 
(PARAMS (33) , INFLOW) 
(PARAMS (37) 1 EELELO} 
(PARAMS (41). TURBID 
(PARAMS (45) , DIGDAT) 
(PARAMS (46) ,MONTH) 
(PARAMS (48) » DAY) 
(PARAMS (50) , YEAR) 
(PARAMS (52) , HOUR) 
(PARAMS (54) ,MINUTE) 
(PARAMS (56) , SECOND) 


CHARACTER*3 AIR,MIX,INFLNT,DISCHG 
COMMON /LSTREC/ LSTREC 


C 
C-- INITIALIZE RECORD COUNT 
Cc 
RECCNT=1 
Cc 
C-- INITIALIZE INDEX 
Cc 
INDEX=] 
€ 
C-- OUTPUT HEADER 
Cc 
CALL HEADER 
Cc 
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C-- WAIT FOR FILE ACCESS IF TODAY'S FILE 


C 

1 IF(TYPE.EQ.1@@) CALL LOCK (2) 
OPEN (8, FILE=FIUNM,STATUS='OLD', IOSTAT=ERRFLG, 
LERR=9880@,ACCESS='"DIRECT', RECL=57) 

18 READ (8, REC=RECCNT, IOSTAT=ERRFLG, ERR=9198) BUFFER 


Vv) 


RECCNT=RECCNT+1 


"IF ( (DIGDAT.AND. #01H) .EQ.#@1H) 


AIR=" ON' 
ELSE 
AIR='OFF' 
ENDIF 


THEN 


IF( (DIGDAT.AND. #62H) .EQ.#02H) THEN 


MIX=' ON' 
ELSE 
MIX='OFF'! 
ENDIF 


IF ( (DIGDAT.AND. #04H) .EQ.#04H) 


DISCHG=' ON! 
ELSE 
DISCHG='OFF! 
ENDIF 


IF( (DIGDAT.AND. ##8H) . EQ. #@8H) 


INFLNT=' ON' 
ELSE 
INFLNT='OFF! 
ENDIF 


WRITE (6,181) MONTH, DAY, YEAR,HOUR,MINUTE,SECOND, 


THEN 


THEN 


1PH, VOLUME, TEMP, DISOXY, TOTCAR, ORGCAR, SUSSOL, PHOSFT, 
2INFLOW, EFLFLO, TURBID, AIR, DISCHG,MIX, INFLNT 

161 FORMAT(I2,'/',12,'/',12,1X,12,':',12,'2',12,1X,F4.1,1X,F9. 2, 
Z1X,F9.4,1X,F9.4,1X,F8.3,1X,F8.3,1X,F9.4, 1X, F9. 4, 1X, F8.3,1X, F8.3 


C 


-~,1X,F7. 3% 


Z1X,A3,1X,A3,1X,A3,1X,A3) 


C-- CHECK FOR END OF FILE AND OTHER THINGS 


Cc 


WwW) 


“INDEX=INDEX+] 
IF(TYPE.EQ.10@) THEN 
IF(INDEX.LE.10) THEN 


IF (RECCNT.LT.LSTREC) THEN 


GOTO 18 
ELSE 


CLOSE (8, IOSTAT=ERRFLG, ERR=9208) 


CALL UNLOCK (2) 
RETURN 

ENDIF 

ELSE > 

INDEX=1 


CLOSE (8, IOSTAT=ERRFLG, ERR=9200) 


CALL UNLOCK (2) 

GOTO 1 

ENDIF 

ELSE 

IF (RECCNT.LE.288) THEN 
GOTO 1@ 

ELSE 


CLOSE (8, IOSTAT=ERRFLG, ERR=9209) 


RETURN 
ENDIF 
ENDIF 

Cc 

C-- ERROR HANDLERS 

C 

9070 WRITE (6,9@01) ERRFLG 

9801 FORMAT('OPEN ERROR IN PRINT; #',14) 
RETURN 

9188 WRITE(65,9101) ERRFLG 

91@1 FORMAT('READ ERROR IN PRINT; #',14) 
RETURN 

9200 WRITE(6,9281) ERRFLG 

92@1 FORMAT('CLOSE ERROR IN PRINT; #',14) 
RETURN 
END 
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ISIS-II PL/M-84 V3.1 COMPILATION OF MODULE INITMD 
OBJECT MODULE PLACED IN :Fl:INITMD. OBJ 
COMPILER INVOKED BY: plm8@ :F]:INITMD.plm DEBUG DATE(18/12/78) PAGEWIDTH (78) 


1 INITMD: 

DO; 

Snolist 

16 1 FQ@GO: PROCEDURE EXTERNAL; 
17 2 END FQ6GO; 
18 l DECLARE semaphore (3) ADDRESS EXTERNAL; 
19 1 DECLARE token (3) STRUCTURE ( 

msgShdr) EXTERNAL; 
20 } INIT: PROCEDURE PUBLIC; 
21 2 DECLARE i BYTE; 


/* initialize semaphores */ 


22 2 (x) CALL FQ@GO; 


oe) 2 DO i= TO 2; 
24 3 CALL RQSEND(semaphore(i),.token(i)); 
25 3 END; 


/* PROGRAM THE 8255 */ 
26 2 OUTPUT (@EBH) =9 2H; 


/* TURN OFF ALL ALARMS */ 


27 2 (2) OUTPUT (@EAH) =8; 


28 42 RETURN; 
29 2 END; 
36 1 END INITMD; 


ASM8#.0V3 :F1:X2CFG.M8@ DEBUG PAGEWIDTH (78) 


ISIS-II 8880/8085 MACRO ASSEMBLER, V2.@ X2CFG PAGE l 
LOC OBJ SEQ SOURCE STATEMENT 
] NAME X2CFG 
2 CSEG 
3 PUBLIC RQRATE 
e0eR8 2000 4 RORATE: DW 32 
5 $NOLIST 
368 $LIST 
361 SNOGEN 
eoae 362 NTASK SET g 
BALB 363 NEXCH SET g 
B00 364 NDEV SET Q 
OB8A 365 NCONT SET 4) 
364 ; 
357 ; BUILD INITIAL TASK TABLE 
368 ; 
369 STD RQADBG, 64,129, ROWAKE 
426 STD ROTHDI,36,112,RQOUTX 
483 STD ROPDSK, 48, 129, RODSKX 
540 STD ROPDIR,48,13@,RODIRX 
597 STD ROPDEL, 64, 131, RODELX 
654 STD ROPRNM ,64,132,RORNMX 
a STD ROAIH, 34,133, ROAIEX 
768 EXTRN  RQHD1 
769 CONSTD CNTROL,RQHD1,8@,CNSTK,81,CONTEX 
882 STD TIMER, 64,20,90 
939 STD TIMUPD,64, 148,90 
996 STD TIMERS,64,141,2 
1853 STD STSINP,64,142,9 
111¢@ STD CHANGE, 64,143,2 
1167 @a) STD REPORT, 808,144,0,18 
1224 STD SCAN, 800,144,98,18 
1281 ; 
1282 ; ALLOCATE TASK DESCRIPTORS 
1283 ; 
1284 GENTD 
1288 ; 
1289 ; ALLOCATE EXCHANGES 
1290 ; 
1291 XCH CONTEX 
1295 XCH FQOLOK 
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/ 


1299 68 INTXCH RQL5EX 


1305 ; ere 
1306 ; BUILD INITIAL EXCHANGE TABLE | 
1307 ; de : 
1308 XCHADR RQDSKX 

1315 XCHADR RQDIRX 

1322 XCHADR RQRNMX 

1329 XCHADR RQDELX 

1336 XCHADR RQAIEX 

1343 PUBXCH CONTEX 


135@ PUBXCH RQLSEX 
1357 PUBXCH FQALOK 


1364 .XCHADR RQINPX 

LOC OBJ SEQ SOURCE STATEMENT 
1371 - XCHADR RQOUTX 
1378 XCHADR RQDBUG 
1385 XCHADR RQWAKE 
1392 _ XCHADR ROQALRM. 
1399 XCHADR RQL6EX 
1466 XCHADR RQL7EX 
1413 XCHADR STSLOK 
1420 XCHADR SETLOK 
1427 XCHADR DSKLOK 
1434 XCHADR BMPTIM 
1441 XCHADR TIMPOL 
1448 XCHADR PRTREQ 
1455 XCHADR CHRESP 
1462 XCHADR. ANRESP 
1469 XCHADR MINS5EX 
1476 XCHADR TIMEEX 
1483 XCHADR RDRESP 
149@ ; 
1491 ; BUILD CREATE TABLE 
1492 ; 
1493 CRTAB 
1500 ; 
1581 ; BUILD DEVICE CONFIGURATION TABLE 
1502 ; ; 
1583 DCT DA,4,8,0 
1544 DCT D1,8,8,1 
1585 ; 
1586 ; BUILD CONTROLLER SPECIFICATION TABLE 
1587 ; 
1588 CST #,80H,5,RQLSEX, CONTEX 
1664 ; 
1605 ; BUILD BUFFER ALLOCATION BLOCK 
1666 ; . 
1687 , BAB 3, BUFPOL 
1627 END 

PL/M-88 COMPILER ~ 18/12/78 PAGE 1 


ISIS-II PL/M-88@ V3.1 COMPILATION OF MODULE CAMMOD 
OBJECT MODULE PLACED IN_ :F1:CAM.OBJ oats 
COMPILER INVOKED BY: plm8@ :F1:CAM.plm DEBUG DATE(1@/12/78) PAGEWIDTH (78) 


] CAMMOD : 
DO; 


/* CONTROLLER TASK STACK */ 


2 1 DECLARE CNSSTK (8@) BYTE PUBLIC; 
6D /* DFS INTERNAL BUFFER SPACE */ 
3 1 DECLARE RQDBUF (7@8) BYTE PUBLIC; 


/* DES STATIC BUFFER POOL */ 


4 1 DECLARE BUFSPOL (1288) BYTE PUBLIC; 


5 1 END CAMMOD; 
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INTRODUCTION 


Companies seeking to develop microcomputer appli- 
cations are faced with two significant problems. First, 
applications are growing more and more sophisticated. 
With competition always present, products are con- 
tinually being enhanced with new features. This bur- 
dens the underlying computer system by increasing 
both the complexity of the software and the number of 
events and functions that must be handled by the 
system. 


The second problem is a management problem. These 
newer and more sophisticated application systems 
must be developed quickly in order to hit shrinking 
market windows. Also, they must be developed with 
lower manpower costs to be feasible in an engineering 
community struck by insufficient technical personnel 
and skyrocketing software development costs. 


These are the needs addressed by the iRMX 86™ Oper- 
ating System. The two goals in the development of this 
product have been power/flexibility to meet the needs 
of increasingly complex application systems, and ease 
of understanding and use, to boost the productivity of 
available engineering resources. Users of Intel’s line of 
iSBC 86™ Single Board Computers or custom-designed 
8086-based boards can now obtain the same benefits 
from Intel supplied system software as they can from 
Intel supplied system hardware. 


The reader of this application note is provided with 
information in four subject areas. 


e The requirements of operating systems are 
discussed along with traditional solutions. 

e The iRMX 86 Operating System is introduced 

and its features are discussed in relation to the 

requirements studied earlier. 

e System design using the iRMX 86 Operating 
System is studied using example solutions. 

e Code for two example systems is examined to 
learn the details of system implementation. 


Some of the topics in this note may not be of interest 
to all readers. For example, an experienced real-time 
programmer may not need to read the entire overview 
of real-time systems. For those who want to brush up 
on a few topics, the overview is organized to allow the 
reader to focus attention on areas of specific interest. 


Throughout this application note, various terms and 
concepts are introduced and discussed. If further 
information on any of these topics is desired, the 
references listed in the front of this note should be 
used. 


OVERVIEW 


This overview is provided to investigate both the prob- 
lems encountered in the design of applications soft- 
ware and also the classical solutions to these problems. 


Multitasking 


A real-time system is defined to be a system that 
reacts to events occurring external to the computer 
and which monitors or controls these events as they 
occur (or in “real-time”). The converse of a real-time 
system is known as a batch system where the outcome 
of a program does not depend on when it is run (for 
example, a payroll program). 


Two other characteristics typically encountered in a 
real-time system are asynchronous event occurrences 
and concurrent activity. The first characteristic is 
caused by events occurring randomly rather than at 
scheduled intervals. The second characteristic, con- 
current activity, takes place when two or more events 
occur nearly at the same time, requiring simultaneous 
activity. 


One method of dealing with the requirements of a 
real-time system would be to write a program that 
knows what events could potentially occur (for 
example, an interrupt occurrence, a real-time clock 
counting down to zero, a byte in memory being 
modified by another program). This program could 
then execute a large loop checking for the occurrence 
of these events. 


There are several problems with this approach. While 
processing one event which has occurred, the program 
is not responsive to other events. Also, the 
programmer has no way of prioritizing the importance 
of the various events. From a maintenance standpoint, 
this program is complex _ difficult to enhance or 
modify. 


The traditional solution to these problems is a tech- 
nique called multitasking. Essentially, this involves 
writing many small routines instead of one large one. 
Each of these routines (tasks) can process events in- 
dependent of the other tasks in the system. In addi- 
tion, a priority can be assigned each task so that the 
operating system can decide as to which task is the 
most important when more than one task neque 
control of the CPU. o 


The support for multitasking involves a scheduler 
which is part of the service provided by the operating 
system. The scheduler allows each task to execute its 
program as if it has sole control of the CPU, ensuring 
that all tasks desiring CPU time are serviced according 
to the priority associated with each task. 
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From the standpoint of system design, multitasking 
has many desirable qualities. Large and potentially 
complex application programs can be decomposed into 
smaller more manageable units. This makes feasible 
the use of programmer teams to implement the appli- 
cation. Perhaps even more importantly, the potential- 
ly overwhelming problems surrounding concurrent exe- 
cution and interrupt handling become transparent to 
the application programmer. Also, multitasking 
makes the modification of existing tasks and the 
addition of new ones become a manageable objective 
since the interaction between tasks is minimized. 


Interrupt Handling 


A common event in a real-time system is the occur- 
rence of an interrupt. Because this event is so com- 
mon, an important feature of a real-time operating 
system is its interrupt processing capabilities. 


From the standpoint of application software, interrupt 
handling can be cumbersome. The currently running 
task must be preempted, various hardware devices 
must be manipulated and perhaps a hardware inter- 
rupt controller must be dealt with. 


A real-time operating system can abstract the occur- 
rence of an interrupt into something more consistent 


with the. way other events are handled. A task can | 


simply inform the scheduler that it does not require 
any CPU time until an interrupt occurs. The relative 
priority of different interrupts can also be handled in 
the same manner as the priority of multiple tasks are 
handled. Thus, the application programmer need only 
deal with the actual processing related to meant 
occurrence. 


Reliability 


Reliability is a keyword in all real-time sustotie In 
this type of system, reliability does not refer to mean 
time between failure. In fact, the software in a real- 
time application typically cannot be allowed to fail. 
The difficulty imposed on the software by the en- 
vironment comes from the near infinite number of. 
permutations that can occur. A system that appears to 
be fully debugged can fail in the field because of a 
combination of simultaneous events that never 
occurred before. 


The only means to avoid failure in these instances is 
through the use of a consistent, well-thought-out 
model for handling events. Any special-cased solution 
is subject to failure when the special cases that were 
Geelgnes for are viclated in the real were 7 


— handling can also ada reliability to an appli- 
cation system. When the application software is 


unable to anticipate the outcome of certain conditions, 
or the software has undiscovered bugs, it is vital for 
the operating system to gracefully handle the situation 
and allow for further processing to continue as ‘best as 
possible. : 


10 Handling 


Many applications for 16-bit microcomputers require a 
variety of I/O devices. The support for I/O opera- 
tions on these devices is typically provided by the 
operating system. Both sequential access and random 
access devices are typically encountered and, in addi- 
tion, flexibility in handling I/O requests and acknowl- 
edgements is important. 


The flexibility necessary typically involves the sched- 
uling of a task’s execution after an I/O request has been 
made. The greatest flexibility can be obtained by an 
asynchronous I/O system. In this system, a task makes 
an I/O request by calling the operating system. Once 
the processing of the request has begun, control is 
returned to the calling task. 


if ee manner, the task can continue executing its 
program while the I/O operation is progressing. When 
the results of the operation are desired, the task can 
call the operating system again to wait for the com- 
pletion of the previous I/O request. 


The second type of I/O support is less flexible but also 
easier to use. An operating system that supports syn- 
chronous I/O allows a task to make a single operating 
system call to make an I/O request. Once control is 
returned to the calling task, the I/O operation is 
complete and the results are immediately available. 
This type of I/O support sometimes takes advantage of 
a technique known as autobuffering to regain some of 
the performance advantage of the overlapped I/O 
found in the asynchronous system. 


Debug Support 


The inherent characteristics of the tealtinie environ- 
ment sometimes make it difficult to debug new soft- 
ware. If the simultaneous occurrence of two events 
causes a bug in the software, detection may be difficult 
because the next time the system is run the error is not 
reproduced. Also, because of the fact that the software 
is broken down into many independent tasks, the in- 
teraction may be difficult to track using standard 
debugging pecumduices 


The solution to these oo ieae is a piece of software 


called the system debugger. The debugger oe 
has three characteristics. 
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1) It is designed to interact with the operating system 
and therefore has intimate knowledge of code, data 
structures and system objects. 

2) Since the debugger is just another task in the 
system, it does not affect the operation of the other 
tasks that are running. 

3) Through the use of sophisticated breakpointing 
facilities, the debugger allows the designer to track 
the tasks in the system, investigate their interac- 
tion with other tasks and selectively stop one or 
more tasks without stopping the entire system. 


Multiprogramming 

In some application systems, there arises the require- 
ment to run several “applications” on the computer at 
the same time. This may be due to the desire to 
squeeze more use out of the hardware or it may be due 
to some system design consideration. These separate 
“applications” (often termed jobs) share many system 
resources (especially the CPU) but at the same time 
they need to be protected as much as possible from 
other jobs. In essence, it should be possible to develop 
two jobs independently and then run them both on the 
same hardware without any interaction. If interaction 
is desired, the operating system should support some 
well-defined protocol for jobs to use to communicate. 


Free Space Management 


One of the most important resources in the computer 
system is the memory. In some applications, the 
amount of memory needed can be determined when 
the system is designed. In the more general case, the 
amount of memory needed by the system fluctuates. 
One solution to this management problem is to have 
available the amount needed in the worst possible 
case. A more flexible and economical solution is to 
dynamically allocate memory from a central pool upon 
demand and return it when possible. This service 
provides two tangible advantages. First, total memory 
needs are reduced. Second, this service allows for ease 
of use by the application programmer because there is 
_no need to set aside blocks of memory and implement 
code to maintain information about current usage. 


File Management 


The ability to easily store and retrieve data stored on 
mass storage devices is a requirement in many appli- 
cation systems. Devices such as disks, tapes and bubble 
memories are used to store program code, data files 
and parameter tables. The operating system is called 
upon to store and retrieve the data and organize it 
such that application programs can easily find and 
manipulate the data when necessary. 


Typically, this service is provided through the use of a 
file system. The mass storage device is partitioned into 
blocks and logical addresses are assigned to the blocks. 
Files are created to serve as directories where the 
names of other files can be cataloged and looked up. 


In many systems, the directory structure can go many 
levels deep (see Figure 1). This provides several advan- 
tages. Directory searches can be done much faster if 
the general area where a file exists is known. Also, if 
several jobs are running at the same time, each can be 
given its own directory and therefore isolated from the 
others. Lastly, for human users, it is much easier to 
manage the information on the disk when some logical 
structure of files exists. 


OBSTETRICS 
GYNECOLOGY 


ROOT 
DIRECTORY 


EMPTY 
DIRECTORY 


PRENATAL 
DELIVERY 


IN-LABOR 
POST-PARTUM 


EMPTY 
DIRECTORY 


IN-PATIENT 
OUT-PATIENT 
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Figure 1. Hierarchical File System 
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Device Independence | | 
One of the unfortunate characteristics of I/O devices is 
that they all tend to present different interfaces to the 
system software. When this is the case, the application 
programmer must become familiar with the unique 
characteristics of each device in order to communicate 
with it. One solution is to create an I/O driver which 
does the actual I/O. This driver can then be called by 
the application program whenever communication 
with the device is desired. 


The problem with this solution is that the programmer 
must still know what type of device is being talked to 
since the I/O driver is specialized. If the system con- 
figuration changes, all of the software must be 
rewritten to call new device drivers. The best solution 
is to design a standard interface to device drivers and 
postpone until run-time the decision about which 
devices to use. With this type of system, an application 
program can be written assuming that at run-time the 
human or program that invokes it will provide a speci- 
fication of which devices should be used. 


High-Level Man-Machine Interface 


In addition to the services provided for application 
programs by the operating system, a set of services 
typically is offered to the human user sitting at the 
system console. System utilities are needed for file 
copying, disk formatting, and directory maintenance. 
Programs need to be loaded off disk to run and the 
programs themselves must be able to retrieve 
parameters passed to them by the operator. All of 
these functions are usually provided by the man- 
machine interface software in the operating system. 


Make Versus Buy 


The previous sections dealt with operating system re- 
quirements. These requirements are encountered in 
the application development process. Whether the 
solution to meet the needs comes from the individual 
application designer or from a computer system 
vendor, the requirements do not change. 


There usually exists a rather simple tradeoff between 
designing a custom operating system or buying a 
generalized system and tailoring it to the individual 
needs of the application. There are advantages to the 
custom solution. The system can often be made 
smaller since the requirements are known in great 


detail. Also, some small performance improvements. 


can sometimes be made by taking advantage of the 
special cases to speed things up. 


Buying an operating system from a computer system 
vendor offers five advantages. 


1) Engineering resources are becoming scarce. The use 
of an opearting system from a vendor allows atten- 
tion to be focused on the application software. 

2) The time taken to bring the product to market can 
be shortened, thereby gaining a competitive edge 
and generating early revenue. 

3) Long-term maintenance costs can be reduced be- 
cause the vendor supports the Speretine system 
software. 

4) Personnel in all branches of the company can be- 
come familiar with one software architecture and 
apply this knowledge to a range of products. 
This applies not only to the design engineers, but 
also to quality assurance, customer engineers and 
system analysts. 

5) The computer system vendor has knowledge of 
future technological advances coming in the prod- 
uct lines. For this reason, the operating system can 
be constructed so that applications software can be 
transported to future hardware without the need 
for expensive redesign. 


In summary, the trade-offs are clear. An operating 
system from a computer system vendor is not the 
answer for every application. But in most cases, the 
most economical and safest bet is to take advantage of 
the expertise of the vendor for the system software 
and use engineering resources to more quickly solve 
the application problem. 


INTRODUCTION TO THE iRMX 86™ 
OPERATING SYSTEM 


The iRMX 86 Operating System meets the needs of 
real-time applications while simultaneously providing 
the full set of services normally found in a general- 
purpose operating system. 


The overall picture of the iRMX 86 Operating System 
is shown in Figure 2. The iRMX 86 Nucleus provides 


HUMAN INTERFACE 


USER APPLICATIONS 


| Figure 2. Layers of Supportin the iRMX 86™ System 
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support for multitasking, multiprogramming, inter- 
task communication, interrupt handling and error 
checking. The Basic I/O System provides support for 
device independent and file format independent 
manipulation of data on I/O devices. The Extended I/O 
system provides synchronous I/O calls, automatic 
buffering, logical file name support and high-level job 
management. The application loader provides the 
ability to load code and data from mass storage devices 
into RAM memory. The Human Interface provides for 
a high-level man-machine interface as well as file 
utilities and parsing support for application programs. 


The following sections deal in more detail with each of 
these iRMX 86 pieces. If more information is desired on 
the features discussed, please refer to the documents 
listed in the front of this application note. 


Architecture 


The iRMX 86 architecture is an object-oriented archi- 
tecture. This means that the operating system is 
organized as a collection of building blocks that are 
manipulated by operators. The building blocks of the 
iRMX 86 system are called objects and are of several 
types. Some of the object types are tasks, jobs, mail- 
boxes, semaphores and segments. These types are 
explained in subsequent sections of this application 
note. 


This type of architecture has two major advantages. 
First, the system is easier to learn and use. The at- 
tributes of the various objects and the operations that 
can be performed on them are well defined and con- 
sistent. Once an object type is understood, all objects 
of that type are understood. 


The second advantage to an object-oriented archi- 
tecture is the ease with which the operating system 
can be tailored to the application. If there is no need 
for a given object in the application, all operators for 
that object are not included in the final configured 
system. On the other hand, if the application designer 
needs a more complex building block that is not in the 
basic system, he can define and use a new object type. 


Table 1 lists all of the system calls in the iRMX 86 
Nucleus. There are three groupings of system calls in 
this table. 


1) The general system calls apply to all objects uni- 
formly. 

2) The first two system calls for each object are the 
create and delete calls. These calls simply create a 
new object and initialize its attributes or delete a 
existing object. : 


3) The remaining system calls are specific to the at- 
tributes of a particular object. With this organiza- 
tion in mind, the entire operation of the iRMX 86 
nucleus can be glimpsed in a single table. 


Tasks 


Tasks are the active objects in the iRMX 86 archi- 
tecture. Tasks execute program code and therefore are 
the only objects that can manipulate other objects. The 
attributes of a task include its program counter, stack, 
priority and dispatcher state. 


Tasks compete with each other for CPU time and the 
iRMX 86 scheduler determines which task to run based 
upon priorities. The dispatcher states for an iRMX 86 
task are shown in Figure 3. At any given point in time, 
the highest priority task that is ready to run has 
control of the CPU. Control is transferred to another 
task only when 


(NON-EXISTENT) 


asteep Jy 4) ~—s | RUNNING | ___. (©) ss | susPENDED 


(8) 


“\. | ASLEEP-SUSPENDED 


(8)L__A 
_ 


(10) 


(NON-EXISTENT) 


Figure 3. Task State Transition Diagram 


1) the running task makes a request that cannot im- 
mediately be filled and is, therefore, moved to the 
asleep state, | 

2) an interrupt occurs causing a higher-priority task to 
become ready to run or 

3) the running task causes a higher-priority asleep 
task to become ready by releasing some resource. 


The suspended and asleep-suspended states are 
entered whenever the suspend system call is invoked 
for a particular task. 


Job and Free Space Management 


Support for multiprogramming is provided by the job 
object. A job provides the environment for tasks to 
execute their programs. All other objects needed for a 
particular application are contained within the job. 
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Table 1. Nucleus Object Management System Calls 


System Calls for Object- aera 


Tasks 


Memory pool 
Object directory 
| Exception handler 


Priority 
Stack 
Code 
State 
Exception handler 


CATALOGSOBJECT 
UNCATALOGSOBJECT 
LOOKUP$OBJECT 
ENABLES$DELETION 
DISABLE$DELETION MAILBOXES 
FORCESDELETE 


GETS$TYPE 


List of tasks waiting for critical 


section 


SEGMENTS Buffer with length 


List of objects. 
List of tasks waiting for objects 


SEMAPHORES | Semaphore unit value 
List of tasks waiting for units 


CREATE$JOB 
DELETE$JOB 
SETS$POOLS$MIN 
GET$POOL$ATTRIB 
OFFSPRING 


- CREATESTASK 
DELETESTASK 
SUSPEND$TASK 
RESUMES$TASK 
GETSEXCEPTIONSHANDLER 
SETSEXCEPTIONSHANDLER 
SLEEP 
GET$TASK$TOKENS 
GET$PRIORITY 
SET$PRIORITY 


CREATE$SSEGMENT 
DELETE$SEGMENT 
GETS$SIZE 


CREATE$MAILBOX 

| DELETE$MAILBOX 

| SEND$MESSAGE 
RECEIVESMESSAGE 


CREATE$SEMAPHORE 
DELETES$SEMAPHORE 
RECEIVESUNITS 
SENDSUNITS 


CREATE$REGION 
DELETESREGION 
RECEIVE$CONTROL 
ACCEPT$CONTROL 
SEND$CONTROL 


License rights to a given extension CREATESEXTENSION 
type DELETESEXTENSION 


New object template 


A specific attribute of the job is a free memory pool 
from which blocks can be allocated only by tasks 
within the job. Also, the job contains an object direc- 
tory which can be used by tasks to catalog objects 
under ASCII names so that other tasks, knowing the 
ASCII name, can look up the obj ect and pa gain 
addressability to it. 


More than one job can co-exist in the computer system. 
Tasks within jobs can also create children jobs forming 
a hierarchical tree of jobs (see Figure 4): Each job in 
the system has its unique set of contained objects, its 
own memory pool and its own object directory. 


Segments | 


A fundamental resource that tasks need is memory. 
Memory is allocated to tasks in the form of the 


TERMINAL 
HANDLER 


Figure 4. iRMX 86™ Job Tree Example 


CREATES$COMPOSITE 
DELETES$COMPOSITE 
INSPECT$COMPOSITE 
ALTER$COMPOSITE 


ROOT JOB 


DEBUGGER USER JOB 
USER JOB USER JOB USER JOB 


segment object. The segment is a block of contiguous 
memory. The attributes of a segment are its base 
address and size. A task needing memory requests a 
segment of whatever size it requires. The Nucleus 
attempts to create a segment from the memory pool 
given to the task’s job when the job was created. 
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If there is not enough memory available, the Nucleus 
will try to get the needed memory from ancestors of 
the job. 


Communication and Synchronization 


In many cases it is necessary for two tasks to com- 
municate in order to exchange data and commands. 
This is supported through the use of an object known 
as a mailbox. As its name implies, a mailbox is a 
holding place for objects. One task can send an object 
to a mailbox, causing the object to be queued there. 
Another task can later receive an object from the mail- 
box and thereby gain access to it (see Figure 5). If a 
task tries to receive an object from a mailbox and there 
are no objects there, the task can optionally be made to 
sleep for a specified time for an object to appear. 


MAILBOX 


TASK B 
(RECEIVER) 


TASKA 
(SENDER) 


MAILBOX 
Y 


Figure 5. Intertask Communication via Mailboxes 


Note that any object can be sent to a mailbox to be 
received by another task. Typically, the object sent is a 
segment which is a block of memory and can contain 
any commands or data. The term message is often used 
to describe the object during the time it is being sent 
wneoneD a mailbox. 


In those cases where there is a requirement for syn- 
chronization between tasks but no data need be sent, a 
simpler more efficient mechanism exists. The sem- 
aphore object provides for the allocation of abstract 
entities called units. The primary attribute of the 
semaphore is an integer number. Tasks may send units 
to a semaphore thereby increasing the integer number 
or they can request units, thereby decreasing the 
number. If a task makes a request for more units than 
are available, it can optionally be made to sleep for a 
specified amount of time. This mechanism can be used 
for synchronization, resource allocation and mutual 
exclusion. 


Interrupt Management 


When an interrupt is sensed by the 8086 hardware, a 
user interrupt handler is executed. The interrupt 
handler can either perform all interrupt processing 
itself without making any iRMX 86 system calls, or it 
can signal an interrupt task allowing more general 
interrupt processing including calls to the operating 
system. 


The operating system maps hardware interrupt priori- 
ties into the software priority scheme allowing the 
designer to specify what software functions are im- 
portant enough to have some interrupt levels masked 
off during their execution. Although this mapping 
should always be kept in mind during design, the 
mechanics of dealing with interrupt oe are 
handled by the operating system. 


Error Management 


One of the central themes in the design of the iRMX 
86 operating system has been reliability. The results of 
these efforts are evident in two particular features of 
the architecture. Beyond the ease of understanding 
brought about by the symmetry of the system, the 
reliability of applications. using the iRMX 86 software 
is increased. 


The general case (as opposed to checking only for 
specific combinations of errors) has been designed for. 
Because of this, an unexpected combination of events 
or the simultaneous occurrence of interrupts will 
never catch the system by surprise. 


In the event that errors do occur, the operating system 
is set to detect them. Virtually all parameters in calls 
to the operating system are checked for validity. Any 
inconsistency causes a jump to an error routine to 
handle the problem. Two types of errors can poten- 
tially occur and there are two ways of handling errors, 


The first error type is the programmer error condition 
which comes about due to some mistake i in the coding 
of a system call. The second type is an environmental 
condition which arises due to factors out of the control 
of the engineer (e.g. insufficient memory). Each of 
these error types can be handled in-line by checking a 
status code upon return from the call or can cause an 
error handling subroutine to be called by the system. 
The system designer can choose the desired method for 


the system, for a specific job, and even for individual 


tasks within a | job. 


Asynchronous I/O 


Asynchronous I/O system calls are provided to 


support device independent I/O to any device in the 
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system. The type of I/Oand the type of device are 
interrelated as shown in Figure 6. Every device driver 
in the To system is required to support a standard 
interface. In this manner, all devices look the same to 
higher. level software, In the same manner, the 
individual file drivers, which provide the different 
types « of file systems, all have a standard interface and 
call upon the various device drivers to perform I/O. 
These interface standards 


1) provide for the device independence i in the higher 
layers of the I/O system 

2) make it easier for Intel to add future device drivers 
as new devices become available and 

3) make it possible for iRMX 86° user's to add their own 
drivers for custom I/O devices. 


. PHYSICAL 
FILE 
DRIVER — 


iSBC 206™ 
DRIVER 


TERMINAL 
DRIVER 


| Figure 6.110 System Structure | 


The iRMX 86 I/O system provides both asynchronous 
and synchronous system calls. The asynchronous I/O 
calls are faster, provide more flexibility in the 
selection of options and allow the program making the 
call to perform other functions while waiting for the 
I/O operation to complete. 


The method by which the I/O system responds to the 
requestor is through the use of a mailbox. When any 
call is made to the asynchronous I/O system, one of the 
parameters indicates a mailbox where the caller 
expects to receive a segment containing the results of 
the operation (see Figure 7). 


Synchronous | 0 


The alternative to using the asynchronous T/O system 
is to use synchronous I/O system calls. As shown in 
Figure 8, the number of options available are fewer 
and the caller cannot continue execution until: the 
entire I/O operation is completed but from an ease-of- 
use standpoint, the situation is much simplified. 


Response$mailbox$token : — - RQScreates _ _ 
mailbox (0, @ status); 


CALL RQ$A$read(connection$token, buf$ptr, : 
count, response$mailbox$token, @ status); 


lORS$token = RQ$receive$message 


esponse smal box stonen< OFFFFH, 
@resp$t, @status); . | 


- {check status} 


Call ROSdeletessegment(IORSStoken, 
-@stat US): 


e Figure’ 7. Sia dase i 1/0 Call 


Call BGasercadisonnactionsiokea: but$ptr, 
count, @ status); 


{check status} 


Figure 8. Synchronous I/O Call 


Two other features provided by the Extended I/O 


System are logical name support and autobuffering. 
.Logical names allow the application designer to post- 
pone the decision concerning which files to use until 


run-time. Essentially, all programs can be written and 
compiled using logical file names and then these 
logical names can be mapped into real file names at 
run-time. 


The use of autobuffering regains much of performance 
advantage offered by overlapped I/O. When a user task 
opens a file for input, one or more buffers are auto- 
matically created and filled with data from the file. 
Thus, when the user task makes an I/O request, the 
data may already be available in memory. A similar 
case exists for write requests in that the I/O system 
will buffer data to be written to a device, allowing the 
user task to continue on. | 


Loaders 

The iRMX 86 application loader and bootstrap loader 
perform a variety of services for the user software. 
The following is a brief aumnary of the vo 
features. 7 


1). Systems can be boot loaded from mass storage 
devices at system reset. This saves not only ROM or 

- EPROM memory, but also reduces :field mainte- 
nance costs by allowing easy field updates. : | : 

2) Users can design their own SYSGEN procedure 

_ allowing tailoring of an application system to the 
‘individual installation. . 

3). Infrequently used programs can be brought in isa 
mass storage when needed instead of site system 
memory unnecessarily. ) 
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File Management 


There are three types of files supported by the iRMX 
86 I/O system, named files, physical files and stream 
files. Named files are supported on devices possessing 
mass storage capability. Files in this system have 
ASCII pathnames and are cataloged in directories. 
Each device in the system contains a directory tree as 
shown previously in Figure 1. Access protection is 
provided through the use of access lists for each file. 
Each user or group of users in the system can be given 
different types of access to the file or can be denied 
access to it. | 


For devices that cannot support a named file structure 
(e.g. printers and terminals) the physical file driver is 
used. Devices in this category are treated strictly as 
data going into and/or out of the device. If it is 
desirable to treat a mass storage device strictly as a 
large mass of data, it can also be addressed through 
the physical file driver. 


The third type of file is the stream file. This file type 
has no correlation with any physical device but rather 
uses system memory for temporary storage of data. An 
example of the usage of a.stream file is a job that gets 
its input stream of data from a file. Depending on 
which time the job is run, this file might be a named 
file on disk, a terminal, or a stream file being written 
to by another job (see Figure 9). ? 


RUN 1 
S INPUT 


‘RUN 2 


aa INPUT op et 


TERMINAL 
RUN 3 


INPUT OUTPUT 


C sos )—>C_0 
STREAM 
FILE 


STREAM 
FILE 


Coe’) 


Figure 9. Stream File Example 


Human Interface Subsystem | 


The highest level of support provided by the iRMX 86 
Operating System is the Human Interface Subsystem. 
This piece of software provides two basic services. 
Programs can be invoked by typing the program name 
at the system console. The Human Interface will load 
the given program into memory, set it. up as a job and 
start it running. The invoked program can then call 
upon the Human Interface routines to determine what 
parameters were passed to it as part of the operator 
input. oe 
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The Human Interface also contains a set of system 
utility routines which are used to copy files and disks, 
format disks, cynemneay alter the system configura- 
tion and others. : 


Debugging Subsystem 

The iRMX 86 Debugging Subsystem allows the de- 
signer to interact with the prototype system and iso- 
late and correct program errors. Since the debugger is 
an object-oriented debugger and is aware of the in- 
ternal structure of the operating system, it can provide 
detailed information concerning objects and can mon- 
itor mailboxes and semaphores providing a breakpoint 
facility as well as error detection. 


Specifically, _ the iRMX 86 pase: Subset 
provides six sets of functions: 


1) Wake-up upon operator invocation. The operator 

_ types a control-D key to cause the debugger to 
wake up. 

2) View system lists. The debugger can view lists of 
objects either globally or specifically for a given 
job. Also, lists of objects and tasks queued at mail- 
boxes and semaphores can be seen. 

3) Inspect objects. A detailed report on any object can 
be requested showing the current state of all 
relevant attributes. | 

4) Inspect and modify memory. 

5) Breakpoint control. Any number of breakpoints 
can be set causing a single task to break on either 
execution of particular instructions or sends and 
receives of messages or units. 

6) Error handling. The debugger can be set up to be 
the system default error handler thus catching 
system exceptions. . 


Configuration and Initialization 

Once the application is designed and coded, the 
engineer needs a mechanism to inform the operating 
system of the software and hardware. configuration. 
Essentially, this involves building tables of informa- 
tion using tools provided with the: IRM 86 product. 


As shown-earlier in Figure 4, the jobs i in an. iRMX 86 
system form a hierarchical tree. The root in every job 
tree is known.as the root job and is supplied as part of 
the iRMX 86 system. There are three important fea- 
tures of this job. 7 


1) The root job has an object directory for cataloging 
and looking up objects. The special feature of this 
directory is that is is accessible by all tasks in the 
system since everyone can address the root job. For 
this reason the root object directory is useful for 
setting up inter-job communication paths. 
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2) The root job initially contains all free space in the 
system. Part of the system initialization code per- 
forms a memory scan to automatically determine 
the amount of free RAM in the system. This 
memory is put into the free space pool of the root 
job and parceled out as user jobs are created. 

3) The root job contains only one task, the root task. 
This task scans the configuration tables generated 

_ by the user and creates the user-specified jobs. . 


Examples of configuration, initialization and the 
LINK 86 and LOC 86 operations needed to generate a 
system will be presented in the Code Examples section. 


DESIGN METHODOLOGY 


This section describes the design process involved in 
using the iRMX 86 system to solve application prob- 
lems and presents two example solutions. 


System design with the iRMX 86 Ouseatide System 
should be viewed as a process starting with the highest 
level definition of system requirements and succes- 
sively adding more detail until the end product is 
program code. This description sounds very much like 
the description of top-down design and, of course, it 
should. This methodology offers not only quicker 
designs, fewer design flaws and easier implementation, 
but also easier maintenance and enhancement. 


In general, every iRMX 86 design progresses through 
the following steps: 


1) Define system, requirements. 

2) Breakdown into highest level sub- functions Gobs). 

3) Define job functions. 

4) Determine inter-job command and data flow. 

5) Break down each job into sub-functions. 

6) Based upon requirements, peblgn tasks to perform 
job functions. — 

7) Determine inter-task command a data flow. 

8) Write program code for each task. 


_ Step 8 becomes the rere process associated with the 
application programs themselves. The code for each 
task is essentially a sequential program that performs 
one of the functions of the computer system. Standard 
techniques for top-down design can therefore be used 
here to specify each module and its inputs and outputs 
as well as global and local data structures etc. The end 
product of this procedure is a modularized application 
system that should be easy to aa 


APPLICATION EXAMPLE 1 


The first example presented here is based on the dis- 
tributed local network diagrammed i in Figure 10. Each 


WORK. 
STATION 


WORK- 
STATION |. - 
1 


WORK: 
eee neice 


LOCAL NETWORK 


Figure 10. Block Diagram of Example System 1 


workstation shown is an intelligent terminal having 
local data and program storage. The stations all use 
the File Sharing Node (FSN) for storage and retrieval 
of records in much the same way as the secretaries in 
an office would make use of a filing cabinet. The FSN 
maintains the files on a fixed disk device and responds 
to requests from the workstations for access to the 
data. The design to follow concentrates on the File 
Sharing Node. _ 


System Requirements 


Each intelligent terminal in the network has command 
processing software. When a file reference is made 
that cannot be satisfied by the local file system, a 
request is made to the File Sharing Node. This request 
consists of a log-on request followed by a string of I/O 
requests and ultimately a log-off request. 


The number of intelligent terminals (workstations) 
hooked up to the FSN varies from installation to 
installation. Therefore, the FSN must be capable of 
handling many simultaneous requests and no assump- 


tions can be made about the maximum number of 


workstations or requests that may need to be handled. 


‘Each node in the network has a unique address. A 


packet is sent onto the network by one node and the 
address field is examined by all other nodes. If this 
field does not match the node’s address the packet is 
ignored. If a match is found the packet is Be 
from the network. 


Hardware Requirements 


The three main hardware building blocks needed by 
this application are shown in Figure 11. The iSBC 
86/12A Single Board Computer will communicate 


with the iSBC 544 Intelligent Communications Con- 


troller to establish and maintain communications with 
the network. The Intel 8085A on the iSBC 544 board 
will perform all of the address recognition, acknowl- 
edgements, packet retrieval and packet transmittal. 


The iSBC 206 Hard Disk Controller will be used to 
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create, maintain and access the data files which are at 
the heart of this application. 


iSBC 86/12A™ 
SINGLE BOARD 
COMPUTER 


iSBC 206™ 
HARD DISK 
CONTROLLER 


MULTIBUS™ SYSTEM BUS 


4™ 


iSBC 544 
COMMUNICATIONS 
CONTROLLER 


Figure 11. Hardware Block Diagram 


System Design 


The first step in the system design process is the 
breakdown of the system functions into one or several 
jobs. The reasons for doing this are system modularity 
and protection. With this type of design, each job can 
be designed separately, perhaps even by a different 
engineer or engineering team. The input and output 
requirements will be specified very tightly and the job 
will take on the appearance of a black box to other jobs 
in the system. If the job is enhanced or modified at a 
later date, the rest of the system can be left undis- 
turbed providing that the input and output response 
remains the same. 


The job object in the iRMX 86 operating system also 
affords a degree of software protection for the tasks 
and other objects contained within the job. Each job 
has a separate memory pool, a separate object 


directory and a ae identification to the I/O - 


system. 


The two primary groupings of functions ‘in this appli- 
cation are those related to the network communica- 
tions and those related to processing the file trans- 
action request. A list of a possible split- up of ee 
functions is shown in Figure 12. 
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FILE TRANSACTION JOB: 


COMMUNICATIONS JOB 


¢ RETRIEVE INPUT REQUEST _ 
PACKETS FOR SERVICING. 


¢ DETERMINE WORKSTATION 
STATUS 


© iSBC 544™ INPUT INTERRUPT 
SERVICE 

* iSBC 544™ OUTPUT INTERRUPT 
SERVICE 


rites OUTPUT REQUEST ¢ SERVICE TRANSACTION 
MAILB REQUESTS 


¢ QUEUE PACKETS x INPUT DATA 
AT INPUT MAILBO 


° EUNGHIAA aes ON AND LOG-OFF 
FUNCTIO 


* BUILD AND SEND RESPONSE 
MESSAGES 


* ACKNOWLEDGEMENT 
GENERATION 


Figure 12. Function Split-up 


The communication between the file transaction job 
and the communication job must fulfill two basic 
needs. The communication job will receive interrupts 
when packets addressed to the FSN are received. 
In order to remain attentive to new requests coming 
in, the communications job should have the capability 
to “spool” the requests off to the file transaction job. 
This buffering can be provided by using the mailbox 
object. Segments can be created to contain the packet 
request data and can then be sent to a mailbox where 
the file transaction job can receive and process them. 


When the file transaction job must send a packet to a 
workstation, the requirement is seen for another 
queue of requests. Since the communications board 
can only put one packet at a time on the network, a 
mailbox should be provided to allow tasks in the file 
transaction job to send output request segments into 
the queue and then continue on (see Figure 13). 


OUTPUT 
REQUEST 


MAILBOX 


WORKER 
TASK 


_COMMUNICATIONS JOB 


FILE TRANSACTION JOB 


Figure 13. Output Mailbox Queue 


Since tasks in both the file transaction job and the 
communications job must have access to these input 
and: output mailboxes, some means must be set up to 


“broadcast” the ene for. ss obj ects. 


in the RMX 86 system, edi ebiect has ne 
with it a 16-bit number called a token. Whenever an 
object is referenced in:an operating system call, the 
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token for the object is used. For example, assume that 
‘a segment must be sent to a mailbox. The segment and 

mailbox each have a token and these tokens are passed 

to the operating system as parameters in the 
_send$message system call. 


There are three major ways to get the token for an 
object. The first way is to create an object. Whenever 
the operating system is called to create a new object, 
the value returned from the procedure call is the token 
for the new object. The second way to receive a token 
is through the receive message system call where an 
object is received from the queue at a mailbox where it 
was sent by another task. 


The third major mechanism for the receipt of a token 
is provided by the object directory concept. As men- 
tioned previously, each a in the system has an object 
saa 


Ifa task ; in a job has the token for an object and wishes 
to let other tasks in other jobs have access to the 
object, the task.can “catalog” the object in the object 
directory. The catalog$object system call takes the 
token for an object and an ASCII name as parameters 
and creates an entry in the object directory. If another 
task knows the ASCII name for an object, it can obtain 
the token by performing a lookup$object call. 


The object directory mechanism will be used in this 
example to allow the communications job to “broad- 
cast” the tokens for the input and output mailboxes. 
The jobs for this application are shown in Figure 14. 


ROOT JOB 


COMMUNICATIONS | FILE 
JOB TRANSACTION 


Figure 14. Job Structure 


The next step of the design methodology calls for each 
job to be further divided into sub-functions. In. this 
application note, only the pe transaction job is 
auc’: | 


In time sequence, salie file transaction job will: 


1) Retrieve input requests from the mailbox set up by 
the communication job. 

2) Determine state of specified worksuon (for ex- 
ample, is it logged on?). 

3) Perform I/O operation or log-on or log-off. 

4) Build and send response to the workstation. 


Recall from the discussion of system requirements 


_ that the number of nearly simultaneous requests that 


may be received by the FSN is not known. For this 
reason, some mechanism must be provided to allow 
parallel processing of many requests. This should 
prove feasible since the performance of step 3 will 
involve many delays while waiting for the operating 
system to perform I/O operations. 


One straightforward way to provide for parallel 
processing is to create a task for each workstation that 
logs on. In this manner, each I/O request will be 
handled by a unique task. Through the use of the 
iRMX 86 scheduler, maximum CPU utilization will be 
gained by allowing each task to individually compete 
for CPU time. These “worker” tasks fulfill function 3 
and 4 for the file transaction job. 


Function 1 and 2 can be fulfilled by a single task. This 
task will wait at the input mailbox set up by the 
communications job. When a packet is received that 
requests a log-on operation, the “listener” task will 
create a new “worker” task to handle the request. 
Figure 15 shows a picture of the design. 


WORKER K. 
TASK 


SERVICE 
MAILBOX 
OXES | /output \. 
| REQUEST 


WORKER 
TASK 


FILE TRANSACTION JOB 


Figure 15. Diagram of Design of 
File Transaction Job 


The string of transaction requests that follow will 
simply be demultiplexed by the listener task. The 
workstation ID will be searched for and, if found, the 
packet will be sent to the appropriate worker task. If a 
request comes in from a station that is not logged on, 
an error response is sent directly to the communica- 
tions output mailbox for transmittal to the station 
that made the request. 7 
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If the request packet indicates that a station desires to 
log-off, the listener task will delete all local reference 
to the station and pass the packet along. The listener 
task cannot simply delete the worker since the worker 
may be in the process of servicing a previous I/O 
request. In general, it is never a good idea to arbi- 
trarily delete another task. A better protocol is to pass 
along the message signaling the worker task to delete 
itself when convenient. 


An investigation of the intertask communications 
needs highlights the requirement for passing data 
between tasks. The interjob communications protocol 
discussed earlier specified that the listener task will 
receive input request segments from the communica- 
tions job via a mailbox. 


Within these segments are fields containing the work- 
station ID and the command. Based upon these fields 
one of two things happens. If the command indicates 
that the station wishes to log on, a new worker task 
must be created to process the I/O requests that will 
follow. 


The code executed by all worker tasks will be identical 
since they all perform identical functions. However, 
some unique pieces of information must be passed to a 
new worker task. This can be accomplished by having 
the worker task first wait at a “log on” mailbox. Here it 
will receive a segment from the listener task which 
contains the necessary information (see Figure 16). 


WORKER 


LOG ON INFORMATION 
LISTENER MAILBOX 


TASK 


MAILBOX TOKEN 


RESPONSE 
| MAILBOX TOKEN 


WORKSTATION 
| 


SEGMENT 
FORMAT 


SERVICE 
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Figure 16. Communications Between Listener 
Task and a Newly Created Worker Task 


After this initialization is complete, the workstation 
requests that are received by the listener task can be 
sent to the service mailbox associated with the work- 
station. The token for the service mailbox is one of the 
pieces of information contained in the log on segment. 


The last communication path needed is predefined by 
the interjob communication protocol. When either the 


listener task or one of the worker tasks needs to 
transmit a packet to a workstation, a segment is sent 
to the output request mailbox of the communication 
job. 


The final step in the design methodology is to write 
program code for the tasks in the system. This step is 
performed in the Code Examples section. 


APPLICATION EXAMPLE 2 


This example will deal with the design of a custom 
device driver for the iRMX 86 operating system. As 
shown in Figure 6, a device driver accepts high-level 
commands from the file drivers (such as read, write, 
seek, etc.) and transforms these commands into I/O 
port read and write commands in order to commu- 
nicate with the device itself. By studying the construc- 
tion of a driver for the iSBC 534 Serial Communication 
Expansion Board, a better understanding of the iRMX 
86 I/O system will be gained along with an example of 
the use of nucleus facilities to construct a higher-level 
software function. 


Overview of Device Driver Construction 


Each I/O device consists of a controller and one or 
more units. A device as a whole is identified by a 
device number. Units are identified by unit number 
and device-unit number. The unit number identifies 
the unit within the device and the device-unit number 
identifies the unit among all the units on all of the 
devices. 


A device driver must be provided for every device in 
the hardware configuration. That device driver must 
handle the I/O requests for all of the units on the 
device. Different devices can use different device 
drivers; or if they are the same kind of device, they can 
use the same device driver code. 


At its highest level, a device driver consists of four 
procedures which are called directly by the I/O 
System. These procedures can be identified according 
to purpose, as follows: 


Initialize I/O 
Finish I/O 
Queue I/O 
Cancel I/O 


When a user makes an I/O System call to manipulate a 
device, the I/O System ultimately calls one or more of 
these procedures, which operate in conjunction with 
an interrupt handler to coordinate the actual I/O 
transfers. This section provides a general description 
of each of these procedures, and the interrupt handler. 
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INITIALIZEVO 


This procedure creates all of the iRMX 86 objects 
needed by the remainder of the routines in the device 
driver. It typically creates an interrupt task and a seg- 
ment to store data local to the device. It also performs 


device initialization, if any such is necessary. The I/O » 


System calls this routine just prior to the first attach 
of a unit on the*device (the first RQ$A$PHYSICAL 
S$ATTACHS$DEVICE system call). The time sequence 
of calls to these procedures will be described a little 
later. . 


FINISH 1/0" 


The I/O ‘Syatan ails this procedure after all units of 
the device have. been detached (the last RQ$A$ 
PHYSICAL$DETACH$DEVICE system call). The 
finish$IO procedure performs any necessary final 
processing on the device and deletes all of the objects 
used. by the device handler, including the, interrupt 
task and the device- oe data i Sea 


QUEUE Trem 


This procedure places I/O requests on a queue, so that 
they can start when the appropriate unit. becomes 
available. If the device is not busy, the quewesIO 
procedure starts the request. 


CANCEL I/O 


This procedure cancels a previously queued Bie) 
request. Unless the device i is such that a request can 
take an indefinite amount of time to process (such as 
keyboard input from a terminal), this procedure can 
perform a null operation. 


INTERRUPT HANDLERS AND INTERRUPT TASKS 
After a device finishes processing an I/O request, it 
sends an interrupt to the iRMX 86 system. As a 
consequence, the interrupt handler for the device is 
called. This handler either processes the interrupt 
itself or signals an interrupt task to process the 
interrupt. Since.an interrupt handler is limited in the 
types of system calls that it can make, an interrupt 
task usually services the interrupt. The interrupt task 
feeds the results of the interrupt back to the appli- 
cation software (data from a read operation, status 
from other types of operations). It then gets the next 
VO request from the queue and starts the device 
processing this request. This cycle continues until the 
device is detached. The interrupt task is nora. 
creas by me i 1/0 al : 


The 110 Sata calle aeh one of the four aevite driver 
‘procedures in response to specific conditions. Three of 
the procedures are ee under the poulowing 
conditions. ; 


1) In order to start I/O.processing, the user must make 
~ an I/O request. This can be done by making a variety 
of system calls. However, the first. I/O request to 
each device-unit. must be the RQSASPHYSICALS 
‘ATTACH$DEVICE system call. 

2) The I/O System checks to see if the I/O feqtied 
results from the first RQ5A$PHYSICAL$ATTACH 
$DEVICE system call for the device (the first. unit 
attached in a device). If it is, the I/O System realizes 
that the device has not been initialized and calls the 
initialize I/O proceaure first, before queveing the 
request. 


3) Whether or not the TO Stee called the initialize 


I/O procedure, it calls the queue I/O proceaure to 
queue the request for execution. .. 

4) The I/O System checks to see if the request ‘st 
queued resulted from the last RQ$A$PHYSICAL$ 
DETACH$DEVICE system call for the device (de- 

- taching the last unit of a device). If so, the I/O 
System calls the finish I/O procedure to do any 
final processing on the device and clean a opjects 
used by the device driver routines. 


The I/O System ‘calls the fourth’ device driver 


procedure, the cancel I/O procedure, under the 
following conditions: 


e If the user makes an ROSA$PHYSICALS 
DETACH$DEVICE system call specifying the 
hard detach option, in order to forcibly detach 
the connection objects associated with a device- 
unit. 

e If a job containing the task which made the 
request is deleted. _ 


Each procedure will now be discussed in more detail. 
The initialize $10 procedure takes three parameters: | 


init$io: Procedure (duib$p, ret$data$t$p, status $p) 


The duib$p parameter contains a pointer to a device 


unit information block (DUIB) which is the configu- 


ration table for the device in question. The structure of 
this table is shown in Figure 17. Note that this table 
contains pointers to device and unit information tables 
which can contain hardware specific information (such 
as I/O base addresses, interrupt levels etc.). 


The second parameter is a pointer to a word which can 
be assigned the value of a token for an iRMX 86 object. 
Quite often this object would be a segment which could 
be created. by the init$ie procedure and filled with 
information needed by the other procedures in the 
driver. The token for this segment will be provided to 
the other procedures when they are called. 
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DEVICE UNIT 
INIT$SIO 


CANCELSIO 


DEVICE INFORMATION 
POINTER 
UNIT INFORMATION POINTER 


Figure 17. DUIB Format 


The final argument in the call is a pointer to a status 
word. This word should be assigned by the init$io 
procedure before a RETURN is executed. If a non-zero 
value is returned indicating an error condition, the I/O 
System assumes that init$io has deleted any objects 
created before the error was encountered. , 


The finish$io procedure is called by the I/O System just 
after the last detach$device call is made on the device. 
This procedure is expected to delete any objects 
created by the init$io procedure and shut down the 
connected device. : 


finish$io: Procedure (duib$p, ret$data$t); 


Once again, the first parameter to the call is a pointer 
to a DUIB. The second parameter is the token returned 
by the init$io procedure. 


The queue$io procedure is called to initiate an I/O 
request. 


queue$io: Procedure (IORS$t,duib$p, ret$data$t) - 


The specifics of the request are indicated in an I/O 
request segment (IORS) which is provided by the first 
parameter. The format of this segment is shown in 
Figure 18. The most important fields here are the 
count, function, status and buffer pointer fields which 
tell the quewe$io procedure what needs to be done. The 
second and third parameters are once again the 
pointer to the DUIB and the token for the object 


STATUS 
UNIT STATUS 


ACTUAL 


DEVICE 
UNIT 
FUNC 
TION 
SUBFUNCTION 
DEVICE LOCATION 
BUFFER POINTER 
COUNT 
AUXILLIARY POINTER 
LINK FORWARD 
LINK BACKWARD 


RESPONSE 
MAILBOX 


Figure 18. I/O Request Segment Format 


created by the init$io procedure. 


The final device driver procedure is cancel$io. This 
procedure is called by the I/O System to cancel a 
previous I/O request. If the device is of such a nature 
that a request will complete in a bounded amount of 
time, this procedure can be a null procedure. The 
parameters to the call are identical to those for the 
queue$io call. 


In addition to the elementary support discussed here, 
the I/O System provides extra support to the designer 
of a device driver if some simplifying assumptions 
about the device can be made. Also, if the device 
supports random access (such as disks, magnetic 
bubbles, etc.), support routines can be used to simplify 
the process of blocking and deblocking I/O requests. 
More detail on the process of writing I/O drivers can be 
found in the manual titled “A Guide to Writing Device 
Drivers for the iRMX 86 I/O System.” 


Design of an iSBC 534™ Device Driver 


The following section will discuss an example device 
driver for the iRMX 86 Operating System. The driver 
will be for the iSBC 534 board which contains four 
8251 USART devices; therefore, there is one device 
and four units on the device. | 


The init$io procedure for this driver initializes the 
hardware, creates an interrupt task, creates other 
necessary objects and creates a segment to contain the 
relevant information. 


AFN-01931A 


AP-86 


The structure of the queue$io procedure is moré 
complex. When calls are made to this procedure to per- 
form data reading and writing, the actual operation 
could be somewhat lengthy (especially an input 
operation). Since the queue$io procedure is called by 
the I/O system, it is not efficient to perform the entire 
operation before control is returned to the I/O system. : 


Amore efficient mechanism is to have an independent 
task take the request and fulfill it while the queue$io 
procedure returns to the I/O system allowing other 
operations to be started in parallel. This leads to the 
structure diagrammed in Figure 19. When a read or a 
write request is received, the I/O request segment is 
sent to the request mailbox where it is received by an 
I/O handler task. When the request is complete, the 
I/O task sends the segment to the response mailbox 
indicated in the segment. 


REQUEST 


PROCEDURE mee Or 


_ Figure 19. Queue$io Procedure Interface _ 
_to 0 Tasks 


The remaining design of the device driver is concerned 
with interrupt handling. The iSBC 534 board contains 
four 8251 USART devices. Each device supplies two 
interrupts; one indicating that the receiver has’a data 
character available and the other indicating. that the 
transmitter is ready to accept a character. Each. of 
these interrupis (8 in ail) are connected to one of the 
8259 Interrupt Controllers on the board..The software 
on the iSBC 86/12A board must read a register in the 
8259 controller to determine which of the eight sources 
caused the current interrupt. This information must 
then be fed to the 1/0 task which may be waren for 
the event. 


One way re eet this requirement uses an interrupt 
task for the iSBC 534 board. The task recéives the 
interrupt; determines which device. caused. it, and 
sends a unit to a semaphore to indicate the occurrence 
of the event. Thus, when an I/O task wishes to be 
informed of a‘receiver or: transmitter interrupt, it 
simply tries to receive a unit from the appropriate 
semaphore. If ‘a unit is available, the receiver has a 
character or the transmitter is ready. If the unit is not 


available, ‘the USART is not ready and the task willbe 
put in the asleep state until the aterrupe occurs and 
‘the unit is sent. = 


CODE EXAMPLES 


This chaper will present and analyze some sample code 


for the iRMX 86 applications presented in Chapter 4. 
The code listings are contained in Appendix A and the 
individual modules are numbered sequentially. When 
a specific line or sequence of lines. of code must be 


‘pointed out in the text, a two part number is used 


where the first part is the module number and the 


‘second is the compiler-assigned line number. For 


example, 3.27 would be used to point, ‘out line 27 in 
module 3. . 


A standard set of suffixes to labels will be followed in 
the code to follow. A ‘PL/M- 86 WORD variable that 
will contain the token for an iRMX 86 object will have 


the suffix “$t.” A POINTER variable will be followed 


by “$p” and a structure used to overlay a POINTER 
allowing access to the base and, offset: will be followed 
by (73 $ ‘D $ 0. ” 


Listener Task © 


The Gest module ™ be studiéd sontaine the: stile ne 
the listener task. The various include statements bring 
in literal declarations and external procedure decla- 
rations. The file NUCPRM.EXT: is on the iRMX .86 
diskette and contains the ee declarations for all 
iRMX 86 nucle etn ean 


rig 1. 323 eaitias all” a ths gcse dons fae. the 
module. The literal req$segment$struc is- used. to 
access the fields of a segment returned from the com- 
munications job. The format of a request packet from 
a workstation is shown in Figure 20. The literal node is 
used to access the information in a segment used as a 
workstation descriptor in a list ‘maintained: by the 
listener-task. The format of a node in this list is shown 
in Figure 21. The structure at: the end of the declara- 
tion statement is used to aenenel access the two 
halves of a 32-bit PL/M-86 POINTER. - : 


Note in line 1.330 that the task is coded as a public 
procedure having no parameters..A main procedure 
should never be used for a task’s code since the pre- 
amble for a main procedure sets the stack pon ik 


The sashes to be ase foe nds a newly wented 
worker task an. information segment is called the 
log$on$info$mbox. This mailbox is. created in line 
1.331. Lines 1.332-1.:834 perform: the operation ‘of 
finding the tokens for:the communication job’s input 
and output request mailboxes in the object directory.of 
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. WORKSTATIONID 
a COMMAND 


STATUS 
FILE NAME 
(64) 
BUFFER 
(128) 


Figure 20. Request Packet Format 


TF cesonnano 
-[T servernnnvor 


RESPONSE MAILBOX 


LINK FORWARD 


. Figure 21. Workstation Descriptor Format 


the root job. The token for the root 
the system callin 1.332. | . 


Whenever a workstation logs on, various actions are 
taken by the listener task. One of these actions 
involves adding a descriptor for the workstation to a 
list so that the state of the workstation can be main- 
tained by. the listener task. The list structure is shown 
in Figure 22. Statements 1.3836-1.340 create the root 
of this list-and initialize the list to an empty state. 


Line 1.340-marks: the beginning of an infinite loop. 


Most often a task executes a procedure which performs . 


some initialization and then. enters an endless loop 
performing the necessary processing. The literal “for- 
ever’ translates.into “while 1.” -. 


A packet is received from the input mailbox by the call 


in line 1.341. The command field of the message is. 
checked in line 1.343. If the command indicates that a. 


log on request is being: made, lines 1.345-1.356 are 


executed. A log on information segment.is created in. 


line 1.345. A mailbox is created to handle further 


request packets and another. is: created to be used by. 


the worker. task as a response mailbox.. The worker 


job is obtained by 
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LINK BACKWARD 


LINK FORWARD 
LINK BACKWARD 


LINK FORWARD 
LINK BACKWARD 


Figure 22. Workstation Descriptor List Structure 


task that will handle I/O requests from this work- 
station is created in line 1.351. Note the use of the 
structure data$seg$p$o, which is declared at the same 
address as the POINTER data$seg$p. The POINTER is 
initialized to equal the beginning of the data segment 
of the worker task module (1.323) and then the base 
portion is used as a parameter in the create task call. 


Once the worker task is created, it will wait at the 
log$on$info$mbox for a segment giving it its initiali- 
zation information. The segment is sent in line 1.352 
and received back as an acknowledgement in line 1.353. 
At this point, the segment.is inserted on the list of 
active workstation descriptors by the call in line 1.354. 
Finally the request packet itself is sent to the worker 
task via the service mailbox for the new worker. 


If a log off request is received, lines 1.358 to 1.366 are 
executed. First, the active workstation list is searched 
for the ID of the requesting station. If the station is 
not found to be logged on, the status field is set and 
the request segment is sent to the workstation through 
the communications job. If the station is logged on, the 
descriptor is deleted from the list, the packet is sent 
along to the worker task, and the descriptor is deleted. 


If the command .is anything but log on or log off, lines 
1.3868-1.376 are executed. Once again the station ID is 
checked to see if it is logged on. If not, an error 
message is returned. If the station is logged on, the 
request packet is sent along to the worker task. .- 
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WORKER TASK 


The code for the worker task is shown in module 2. 
Upon creation of a new worker task, a segment is 
received at the log$on$info$mbox (2.242). The data in 
this segment is copied into local variables and the 
segment is returned (2.247). 


The initialization task for this job has already created 


a user object for this job and has also set up a prefix 
which points to the root directory for the disk device. 
These tokens have been cataloged in the root object 
directory. The worker task obtains these tokens 
through the sequence of calls 2.248-2.250. 


The worker task now enters an infinite loop servicing 
the workstation it is assigned to. The specific action to 
be taken by the worker is determined by inspecting the 
cmd field of the request message. 


If the command is a log on, the code from 2.256-2.263 
is executed. The file name specified in the request 
segment is attached and opened and thereby made 
ready for subsequent I/O requests. After this, an ac- 
knowledgement is sent back to the workstation via the 
output$request$mailbox (2.263). 


Ifa log off command is received, the file is closed and 


detached, the service and response mailboxes are 


deleted, a response is sent to the workstation and the 
worker task is deleted. 


If the command is either a read or write command, the 
operation is performed by calling the I/O system. 
When the response.is received, an acknowledgement is 
sent to the workstation. Note that the’ task would 
normally perform more processing. In this example its 
duties have been kept simple. 


POINTERIZE PROCEDURE 


The ASM-86 code for the pointerize support routine is 
shown in Module 3. The token for a segment is the 


base portion of a 32-bit POINTER to the memory. In 


order to access the data in a segment, this 16-bit token 
must be loaded into the base part of a POINTER while 
the offset portion of the POINTER is set to zero. The 
base and offset values are returned in the ES and BX 
regusters as specified by the PL/M-86 calling con- 
ventions. This is the. operation performed by the 
pointerize routine. | 


LIST MANIPU LATION ROUTINES 


Lines 4.1-4.47 provide three subroutines used by the 
tasks in this system to manipulate the list of work- 

station descriptors. Insert$on$list (4.15-4.26) inserts 
the indicated node at the head of the list whose root is 
given as ae first parameter. 


Delete$from$list (4.27-4.35) unlinks the indicated 
node from the list it belongs to. Search$list (4.36-4.46) 
searches a list for the workstation ID given. If the ID is 
not found, a zero is returned. If the ID is found, the 
token for that node is returned. 


At this point an overview of the configuration process 
is needed. A more detailed coverage of the process of 
configuring an iRMX 86 system is provided in the 
manual entitled “iRMX 86 Configuration Guide for 
ISIS-II Users.” 


For each iRMX 86 application, the following steps 
must be performed. 


1) Program code for each task in the system must be 
written and compiled or assembled. 

2) Amemory map for the software must be drawn up. 

3) The system software must be linked and located. 

4) The application jobs must be linked and located. 

5) Tables of configuration data must be drawn up. 

6) The tabular data from step 5 must be formatted 
into a memory data block through the use of a set 
of ASM-86 macros provided with the iRMX 86 
product. 

7) The root job must be linked and located. 


The code executed by the root task is part of the iRMX 
86 system code. This task is initially the only task in 
the system. The root task will access the data block 
constructed by the ASM-86 macros and will create the 
user jobs specified by the macros. The data for the 
configuration process for example 1 is shown in 
Appendix B. 


The first page agains the memory map for the 
example. The iterative link and locate process to put 
these pieces together begins on the second page. The 
LINK86. and LOC86 commands shown place the 
iRMX/86 nucleus into memory. The LOCATE map 
indicates that the last memory location used by the 
nucleus was 077DFH. Therefore, the next contiguous 
piece, the I/O system, is located at O77EOH. 


This process is repeated for the remainder of the jobs 
in the system. 


When the link and locate process is complete, the 
information for the ASM-86 macros must be brought 
together. Worksheets are provided in the iRMX 86 
configuration guide to simplify this Erocers, 


The filled-out rorkaliests for ne macros are shown i in 
the appendix. A configuration file is constructed using 
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the editor and the worksheet information is entered 
into this file. When the file is complete, the con- 
figuration table is created by assembling the file 
CTABLE. A86. This file accesses the configuration file 
built earlier. 


The configuration tables are then linked and located 
together with the code for the root task and the system 
generation process is complete. 


EXAMPLE 2 


INIT$SIO AND FINISH$IO 


The start$and$finish module (5.1-5.371) contains the 
code for the init$534$i0 and finish$534$io pro- 
cedures. The init$534$io0 procedure creates a seg- 
ment, shown in Figure 23, which is used to hold the 
various pieces of information needed by the other 
driver procedures (5.323). The discussion of this 
procedure in Chapter 4 pointed out that any errors 
encountered in the initialization are indicated by the 
non-zero status and that the assumption is made that 
any partial creations must be cleaned up by the init$io 
procedure. This assumption is carried out by the check 
at line 5.324 (and the others at 5.331, 5,335, 5.339 and 
5.342). : | 


INTERRUPT LEVEL 


10 BASE 
ADDRESS 


INTERRUPT 
PENDING SEMAPHORE (8) 
INTERRUPT TASK TOKEN 

REQUEST MAILBOX TOKEN 


USART COM. 
MAND PORT (4) 


Figure 23. init$534$io Segment Format 


The device information contained in the device unit 
information block for this device is retrieved in line 
5.328-5.329. A mailbox to be used for sending I/O 
request segments to the I/O handler tasks is created in 
line 5.330. The interrupt task for this job is created by 
the call in line 5.337. | | 


The do loop starting at line 5.340 is executed to create 


eight semaphores to be used by the interrupt task to 


indicate the occurrence of an interrupt. Note that the 
initial value of the semaphore is zero (no interrupt 


pending) and the maximum value is one. Since the 
nature of the 8251 USART device does not support 
buffering, when a new character overruns the previous 
character before the interrupt can be serviced, the 
data is lost. Therefore, there is no need to indicate the 
occurrence of multiple interrupts pending on the same 
device. 


The call at line 5.345 initializes the programmable 
devices on the iSBC 534 board. If execution has 
proceeded to line 5.346, the initialization is complete 
and a zero status is returned. If an error occurred at 
any point, the code in lines 5.348-5.356 will clean up 
the partial initialization. 


The finish$534$io procedure (5.358-5.370) undoes the 
work of the init$534$io0 procedure. The segment, 
mailbox, interrupt task and semaphores are all 
deleted. 


The queue$534$io procedure is shown in lines 6.1- 
6.382. In line 6.322 the function field of the I/O 
request segment is checked to see if it-is within 
bounds. If it is not, a bad status code is returned. If the 
function is valid, a do case block is executed using the 
function code as the index. 


If a read request is encountered, the auxiliary pointer 
is set to point to the ret$data structure (initialized 
earlier by the init$534$io procedure). In line 6.327 the 
segment is then sent to the request mailbox to be 
received and processed by an I/O processor task. In 
lines 6.330-6.334 the same action is taken with write 
requests. | , 


Since this driver does not support seeking and special 
functions, the code for these two cases simply returns 
an error condition. 


In the case of an attach$device call, the code in lines 
6.341-6.361 is executed. First, two I/O. processing 
tasks are created. All of these tasks execute identical 
code and each task is capable of servicing a read or a 
write request on any 8251. Two tasks are created for 
each 8251 device so that the peak load can always be 
handled (that is, all receivers and transmitters going 
simultaneously). Lines 6.346-6.357 perform the initi- 
alization of the 8251 USART and the baud rate gen- 
erators for this channel. The calls in line 6.358 and 
6.359 accept an interrupt and a character from the 
semaphore associated with the receiver just initialized. 
This is done to clear off an interrupt generated by the 
8251 whenever it is initialized. : 


In the case of a detach$device call, the code in lines 
6.363-6.367 sends the I/O request segment to the 
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request mailbox twice. This is done to signal. two of. the 
I/O handler tasks to delete themselves. As discussed 
earlier in the attach$device section, none of the I/O 
handler tasks is any different from any of the others. 
There are two created for each 8251 device which is 
attached. The protocol set up for their deletion is 
shown here. When an I/O handler task receives a 
segment of type “detach$device” it will send the 
segment to the response mailbox and then delete itself. 


The code for the open and close requests is the same. 
Both cases are supported but are NOPs since no 
specific action needs to be taken by the driver. 


Lines 6.379-6.382 contain the code for the cancel$ 
534$i0 procedure. As discussed earlier, this pro- 
cedure is simply a placeholder and serves no par- 
ticular purpose. 


INTERRUPT CONTROL MODULE 


The interrupt handler and interrupt task are shown in 
lines 7.1-7.329. The interrupt task is the first piece 
executed. It is created by the init$534$io0 procedure. It 
calls RQ$set$interrupt in line 7.325 to indicate to the 
iRMX 86 nucleus that it is an interrupt task. 


Once the initialization is complete, the task enters an 
infinite loop. The call to RQ$wait$interrupt in line 
7.322 causes the task to be put into the asleep state 
until an interrupt occurrence is signaled. The task will 
be returned to the READY state when an interrupt 
occurs, the interrupt handler is started, and the call to 
RQ$signal$interrupt is executed at line 7.312. The 
current interrupt level is then determined by polling 
the 8259 chip on the iSBC 534 board. Using the 
encoded level number, a unit is sent to the appropriate 
semaphore to indicate that an interruptis pending. _ 


VO TASK 


The final procedure that makes up this driver contains 
the code for the tasks that perform the actual I/O to 
the iSBC 534 board. The loop executed by each task 
starts by waiting at the request mailbox for an I/O 
request segment. When the segment is sent by the 
queue$534$I0O procedure, its function code is checked 
(line 8.327, 8.332, 8.340). If the function is /$ 
detach$device, the task sends the segment to the 
response mailbox and then deletes itself. 


If the request was for a read, the task fills the buffer 
with input data. The call at line 8.334 waits for a unit 
at the semaphore which will indicate a receiver ready 
on the input line. When the unit is sent by the in- 
terrupt task, the character is read in, the pointers and 
counts are updated, and another unit is requested. 


The last request which is recognized by the I/O task is 
for a write operation. The code for this request: is 
almost identical to the. code for a read request. An 
interrupt from the transmitter is awaited, a character 
is output and the counts are updated in lines 8.341- 
8.346. : 


Once the request is fulfilled, the message is sent to the 
response exchange in line 8.350. 


The configuration of this system is studied next. The 
code for the iSBC 534 driver is linked directly to the 
rest of the I/O system libraries. The entry point 
addresses for the queue$534$io, cancel$534$io, init$ 
534$io, and finish$534$io procedures are declared in 
the IOCNFG.A86 file on the I/O system disk. This file 
also contains the device unit information block (DUIB) 
structures for the four units on the iSBC 534 board. 
The unique information for the iSBC 534 device and 
the units on the device is contained in the device and 
unit information tables. Pointers to these tables are 
contained in the DUIB structures. All of this 
information is shown in Figure 24. 


The submit file used to build an I/O system using the 
iSBC 534 driver is shown in Figure 25. The file 
DRV534.LIB contains the object files generated by 
PL/M-86 and ASM-86 from the source code shown in 
modules 5-9. 


SUMMARY 


This application note is an introduction to the iRMX 
86 Operating System. The requirements of operating 
systems were studied along with traditional solutions. 
Following this, the iRMX 86 Operating System was 
introduced and its correlation with the requirements 
was studied. 3 


Later in the application note, the topic of system 
design was covered. Example solutions were studied to 
solidify a methodology for solving application 
problems and then the code for these solutions was 
discussed to gain insight into the details of imple- 
menting iRMX 86 systems. | 


The purpose of a configurable, real-time, multi- 
purpose operating system is to provide a solid foun- 
dation for application software. The iRMX 86 system 
provides this foundation, giving the software engineer 
a means to quickly and easily implement new designs. 
In addition, the iRMX 86 architecture is the bridge to 
future technology providing the designer with an up- 
grade path to future hardware and software products. 
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extrn init534io: near 

extrn queue534io: near 
extrn cancel534io: near 
extrn finish534io: near 


Duib(8): iSBC 534, unit ] 


efine duib < 
"{534.1', > name (14) 


QR Qire ss we 


03H, ; SuppSopt 
08033H, ; file drivers 
; granularity 
device size 


BD DW QA Vw 


device 

unit 

device unit 
initSio 
finishSio 
queueSio 
cancelSio 
device info 
unit _info 


initS34io, 
finish534io, 
queue534io, 
cancel534io, 
dev 534 info, 
unit 534 1 info 


me we MO Me Me Me Me Ne MO 


& 
& 
& 
& 
& 
& 
& 
& 
& 
& 


Vv 


: 534 device info 


dev_534 info dw ; level 

db ; priority 

db > base address 
? 


; unit info: iSBC 534.4 


? 
unit 534 @ info db ; usart$cmd 
dw * baud rate 


7; unit info: iSBC 534.1 


unit 534 1 info db > usartScmd 
~ dw > baud rate 
; 


; unit info: iSBC 534.2 

7 

unit 534 2 info db > usartScmd 
~ dw ; ; baud rate 

: unit info: iSBC 534.3 


unit 534 3 info db ; usart$cemd 
dw ; baud rate 


Figure 24. IOCNFG A86 File Entries for iSBC 534™ Driver 


los(date,origin) 
Sample I/O System .csd file to link and locate an I/O System. 


This file links an I/O System with the timer included. 


This .csd file assumes the I/O System configuration module is 
iocnfg.a86 (found on the release diskette). 


The origin parameter sets the low address of the I/O System; 
all the segments are contiguous in memory. 


@ Me Me Ne Me Ne Me Me MS Me Ne 


asm86 :flz:iocnfg.a86 date(%#) print(:f£5:iocnfg.1st) 
link86 & 
:fl:ios.lib(ioinit), & 
:iocnfg.obj, & 
:ios.lib, & 
:drv534.lib, & 
erpife.1ib & 
to :fl:ios.ink map print(:fl:ios.mp1) 
loc86 :fl:ios.ink to :fl:ios map sc(3) print(:fl:ios.mp2) & 
oc(noli,nopl,nocm,nosb) & 
order(classes(code,data,stack,memory)) & 
addresses(classes(code(%1l))) & 
segsize(stack(®@)) 


Figure 25. Submit File for Generating an I/O System with the iSBC 534™ Driver 
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Module 1 


ISIS-II PL/M-86 V2.@ COMPILATION OF MODULE LISTENERMODULE 
OBJECT MODULE PLACED IN :Fl:listen.OBJ 

COMPILER INVOKED BY: pim86 :Fl:listen.pim PRINT(:F1: LISTEN. LST) 
DEBUG COMPACT. OPTIMIZE(3) ROM DATE(5/28/8@ 


1 


GH 


24 


listenerSmodule: 
do; 


[IGRI III III IIIT IIT TOTTI IOI IRI IATA IK 


LISTENER: TASK. 


This task creates segments, sends them to the input service 
job to be filled with input packet info. Upon response 

the info is checked to see what action needs to be taken. 
If a logSon request is sensed, a worker task, service 
mailbox, and response mailbox are created and the packet is 
sent along to the worker task. If a logS$off is sensed all 
local reference to the workstation is deleted and the packet 
is sent along to tell the worker to delete himself. If an 
I/O request is sensed the station ID is checked to make 
sure it is logged on. If it is, the packet is sent along to 
the worker. If it isn't an error packet is sent back to the 
requesting workstation. 


ek te tek KK KK KK Bk KK IK I IK HK KKK KH KKK IK KKK RIK KK EK KEK EKER REE KEKE REREEKEKRE / 


Sinclude(:£2:common.lit) 

SSAVE NOLIST 

Sinclude(:f1l:node.lit) 

/* literal declaration of: node descriptor for list utilities */ 


declare 
node literally 'structure( 

linkSf word, 
linkSb word, 
workSstationSID word, 
serviceSmboxS$t word, 
workerS$taskS$t word, 
respSmboxSt word) '; 

Sinclude(:fl:lstutl.ext) 

/* external declarations for list manipulation utilities */ 


Ssave nolist 

Sinclude(:fl:pointr.ext) 

/* external declaration of pointerize procedure */ 
S$save nolist 

Sinclude(:fl:rqpckt.lit) 

/* literal declaration for request packet structure */ 


declare req$segment$struc literally ‘structure ( 
funct word, 
count word, 
actual word, 
exSval word, 
workSstationSID word, 
cmd word, 
share word, 
mode word, 
Status word, 
fileSname (64) byte, 
buf (128) byte)'; 
Sinclude(:f2:nucprm.ext) 
SSAVE NOLIST 


workerStask: procedure external; 
end workerStask; 
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Module 1, continued 


323 ] declare ; 
beginSlistenerStaskS$data byte public, 
begin$workerStaskS$data byte external, 
logSonSinfoS$SmboxSt token public, 
exSval word, 
logSonS$mboxSname (7) byte data(6,'LOGSON'), 
packetSsize literally '132', 
fSread literally '5', 
fSwrite literally '6', 
logSon literally '@', 
logSoff literally 'l', 
notS$loggedSon literally 'l', 
(root$job$t,inputS$requestSmbox$t) token, 
(outputSrequestSmbox$t,respSmbox$t) token, 
(workSstationSlistSroot$t,reqSsegmentS$t) token, 
(logSonSinfo$seg$t,dummySt,wsSdescS$t) token, 
(reqSsegment$p,workSstation$listSrootSp) pointer, 
(logSonSinfoSseg$p,data$seg$p,ws$desc$p) pointer, 
(reqSsegment based req$segmentS$p) req$segmentSstruc, 
(workSstationSlistSroot based workSstationS$listS$root$p) node, 
(logSonS$info$seg based logSonSinfoSseg$p) node, 
dataSseg$p$So structure(offset word, base word) at(@dataSsegS$p), 
(wsSdesc based ws$descSp) node; 


324 1 returnSerrorSto$wWS: procedure; 
320 Z reqSsegment.funct=fS$write; 
326 2 reqSsegment.status=not$ loggedSon; 
327 2 call rqSsend$message(output$request$mbox$t,reqSsegment$t,@,@exSval) ; 
328 2 return; 
329 2 end; 
33@ 1 Listener: procedure public; /* task */ 
331 2 logSon$ info$mboxS$t=rq$createS$mailbox(#,@exSval) ; 
332 2 rootS$jobSt=rq$get$task$tokens(3,@exSval) ; 
333 2 inputS$ request$mboxS$t=rqSlookupSobject ( 
/* job */ rootSjobst, 
/* name */ @(9,'INPUTSREQ'), 
/* time limit */ OFFFFH, 
/* status ptr */ @exSvai); 
334 2 output$requestSmboxSt=rqSlookupSobject ( 
/*® job */ rootSjobSt, 
/* name */ @(18,'OUTPUTSREQ'), 
/* time limit */ CGFFFFH, 
/* status ptr */ @exSval); 
335 2 respSmboxSt=rqScreateSmailbox(@,@exSval) ; 
336 Z workSstationSlistSroot$t=rq$create$segment(16,@exSval) ; 
337 2 workSstationSlistSroot$p=pointerize(workSstationSlistS$rootSt) ; 
338 2 workSstationSlistSroot.linkSf, 
workSstationSlistSroot.linkSb=workSstationS$listS$root$t; 
339 2 workSstationSlistSroot.workstationSID=9; 
340 2 do forever; 
341 3 reqSsegmentS$t = rgqSreceiveSmessage( 
/* mbox token */ inputSrequest$mboxSt, 
7/*® time limit */  OFFFFH, 
/* response ptr */ @dummySt, 
/* status ptr */ @exSval); 
342 3 req$segmentS$p=pointerize(reqS$segmentSt) ; 
343 3 if reqSsegment.cmd= logSon then 
344 3 - do; 


2-99 AFN-01931A 


_ AP-86 


Module 1, continued | 


345 4 logSon$ infoS$seg$ t=rq$create$ segment ( 
/* size */ 16, oO 
/* status ptr*/ @exSval); 


346 4 log$onS info$seg$ p=pointeri ze ( 
logSonSinfoS$seg$t) ; 
347 4 logSonS$info$seg.service$mbox$ t= 
rqScreateSmailbox(®@,@exSval) ; 
348 4 logSonSinfo$seg.resp$mbox$ t= 
rqScreateS$mailbox(@,@exS$val) ; 
349 4 logSonSinfo$seg.workSstation$ID= 
regqSsegment.workSstation$ID; 
350 4 dataS$seg$ p=@beg inSworkerStaskS$data; 
351 4 logSon$info$seg.workerS$taskS$t= 
rqScreateS task ( ! : | 
/* priority */ 200, 
/* start addr */ @workerStask, 


/* data seg ptr */ dataSseg$pS$o.base, 
/* stack pointer */ @, 

/* stack size */ 520, 

/* task flags */ Q, 

/* status ptr */ @exSval); 


352 4 call rq$sendSmessage( 
/* mbox token */ logSonSinfo$mboxSt, 
/* object token */ logSonSinfoS$seg$t, 
/* response token */ respSmboxSt, 
/* status ptr */ @exSval); 


353 4 | logSonS$infoS$seg$t=rq$receiveSmessage( 
/* mailbox token */ respSmboxSt, 
/* time limit */ OFFFFH, 
/* response token */ @dummySt, 
/* status ptr */ @exSval); 


354 4 call insertSonSlist(workSstationSlist$rootSt, 
logSonSinfoS$segSt) ; 
355 4 call rq$sendSmessage ( 
/* mbox tok */ logSonSinfo$seg.service$mboxSt, 
/* obj tok */ reqSsegmentSt, 
/* response */ @, 


/* status */ @exSval); 
356 4 end; 
357 3 else if reqSsegment.cmd = logSoff then 
358 3 do; 
359 4 wsSdescS$t=searchS$list(workSstationSlistS$rootSt, 
reqSsegment.workS$station$ID); 
360 4 if wsSdescS$t = 9 then 
361 4 call returnSerrorStoSws; 
else 
362 4 do; 
363 5 wsSdescp=pointerize(wsS$desc$t) ; 
364 5 call deleteSfromS$list(. 


wsSdescS$t); 

365 5 call rqSsendSmessage( 
wsSdesc.serviceSmboxSt, 
reqSsegmentSt, 


0, 
@exSval); 


366 S) | end; 
367 4 end; 
else 
368 3 do; ; 
369 4 wsSdescS$t=searchSlist(work$stationSlist$rootSt, 


reqS$segment.workSstationSID); 
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Module 1, continued 
370 4 if ws$descS$t=@ then 
371 4 call returnSerrorStoSws; 
else 
372 4 do; . 
373 5 wsSdescp=pointerize(wsSdesc$t) ; 
374 5 call rqSsend$message ( 
ws$desc.serviceSmboxSt, 
reqSsegmentSt, 
0, 
@exSval); 
375 5 end; 
376 4 end; 
377 3 call rq$deleteS$segment (reqSsegment$t,@exS$val) ; 
378 3 end; /* of do forever */ . 
379 2 end; /* of listener task */ 
380 1 end listenerSmodule; 


MODULE INFORMATION: 


CODE AREA SIZE 


@281H 641D 


CONSTANT AREA SIZE = @@@0H gD 
VARIABLE AREA SIZE = 9§@2BH 43D 
MAXIMUM STACK SIZE = @818H 24D 


694 LINES READ 
@ PROGRAM ERROR(S) 


END OF PL/M-86 COMPILATION 
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ISIS-II PL/M-86 v2. ®@ COMPILATION OF MODULE ‘WORKERTASK 
OBJECT MODULE PLACED IN :Fl:worker.OBJ | 


COMPILER INVOKED By: p1m86 :Fl:worker.plm PRINT (:F1:WORKER. LST) 
DEBUG COMPACT OPTIMIZE (3) ROM DATE (5/28/88) 


1 workerStask: 
do; 
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WORKERSTASK: TASK. 


This module contains the code executed by the worker tasks. 

When started, the task goes to a mailbox to receive a segment 
containing initialization information. Using this information 
the task services a service mailbox performing any I/O functions 
requested of it. When a logSoff request comes in the worker 

task closes and detaches the file and deletes itself. 


HK KK KKK KKK KEKE KEE KEKE KEKE IKE KIRKE KKK KERR KEKE RE KR ERE KEKE EE KERR KREEEKEKRERERERE / 


Sinclude(:f1l:nucprm.ext) 

SSAVE NOLIST 

Sinclude(:fl:iosys.ext) 

S$save nolist 

Sinclude(:fl:node.lit) 

7/* literal declaration of node descriptor for list utilities * / 
Ssave nolist 

Sinclude(:f2:common.lit) 

SSAVE NOLIST 

Sinclude(:fl:pointr.ext) 

/* external declaration of pointerize procedure */ 
Ssave nolist 

Sinclude(:fl:rqpckt.lit) 

/* literal declaration for request packet structure */ 


| 


Ssave nolist 


239 1 declare 
read literally ‘l', 
write literally '5', 
log$on literally '2', 
logSoff literally 13", 
(logSonSinfoSmboxSt, output$request$mbox$t) token external; 


240 1 workerStask: procedure reentrant public; 


241 2 declare 
(logSonSinfoS$segSt,logSonS$respSmboxSt,respSmboxSt, 
roaotS$jobSt,userSobject$t,prefixS$t,iorsst, 
serviceS$mboxSt,connSt,req$seg$t) token, 
(logSonSinfoS$p,req$seg$p) pointer, 

(req$seg based req$seg$p) req$segmentSstruc, 
(logSonSinfo based logSonSinfoSp) node, 
(dummy$t,ex$val,work$stationSID) word; 


242 2 logSonS$infoS$seg$t=rqS$receiveSmessage( 

/* mbox token */ logSonSinfoSmboxSt, 

/* time limit */ OFFFFH, 

/* response ptr */ @logSonSresp$mboxSt, 

/* status ptr */ @ex$val); 
243 2 logSonSinfoSp=pointerize(logSonSinfo$segS$t) ; 
244 2 serviceSmboxSt=logSon$info.service$mbox$t; 
245 2 respSmboxS$t=logSonSinfo.respSmboxSt; 
246 2 workSstation$ID=logSonSinfo.workS$station$ID; 
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Module 2, continued 


call rqSsendSmessage({ 

/* mbox token */ logSonSresp$mboxSt, 
/* object token */ logSonSinfoSsegSt, 
7/* response token */ ; 

/* status ptr */ @exSval); 


root$jobSt=rq$getS$taskStokens(3,@exSval); 
userSobjectS$t=rqSlookupSobject ( 


/* job token */ rootSjobSst, 

/* name */ @(11,'USERSOBJECT'), 
/*® time limit */ OFFFFH, 

/* status ptr */ @exSval); 
prefixSt=rqSlookupSobject ( 

/* job token */ rootSjobSt, 

/* name */ @(6,'PREFIX'), 

/* time limit. */ OFFFFH, 

/* status ptr */ @exSval); 


do forever; 


req$seg$t=rq$receivesmessage( 
/* mailbox token */ serviceS$mboxSt, 


/* time limit */ OFFFFH, 
/* response ptr */ @dummySt, 
/* status ptr */ @exSval); 


req$seg$p=pointerize(req$segSt) ; 


if req$seg.cmd=log$on then 


do; 
call rqSaSattach$file( 
/* user object */ userSobjectSt, 
/* prefix token */ prefixSt, 
/* pathname */ @req$Sseg.fileSname, 
/* resp token */ respSmboxSt, 
/* status ptr */ @exSval); 
iorsSt=rqSreceiveS$message ( 
/* mbox token */ | respSmboxSt, 
/* time limit */ |! OFFFFH, 
/* resp ptr */ @dummySt, 
/* status ptr */ @exSval); 
call rqSdeleteSsegment (iors$t,@exSval) ; 
call raqSaSopen ( 
/* connection */ connSt, 
/* mode */ req$seg.mode, 
/* share */ req$Sseg.share, 
/* resp token */ respSmboxS$t, 
/* status ptr */ @exSval); 
iors$t=rqSreceiveSmessage( 
/* mbox token */ respSmboxSt, 
/* time limit */ OFFFFH, 
/* resp ptr */ @dummySt, 
/* status ptr */ @ex$val); 
call raq$deleteSsegment (iors$t,@ex$val) ; 
req$seg.status=@; 
call rq$send$message( 
/* mbox token */ outputS$requestSmbox$St, 
/* object token */ req$segSt, 
/* resp ptr */ G, 
/* status ptr */ @exSval); 
end; 


else if req$seg.cmd=logSoff then 


do; 
call rq$a$close( 
/* connection */ connst, 
/* resp token */ respSmboxSt, 
/* status ptr */ @exS$val); 
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Module 2, continued 
iorsSt= rgqS$receiveS$message( | 
/* mbox.token */ .° respSmboxSt, > 
/* time limit */ © @OFFFFH,. 
/* resp ptr */..  @dummyst, 
/* status ptr. */ . @exSval); 


call rq$deleteSsegment(iorsSt, @ex$val); 


call rqSa$deleteSconnection ( 


end; 


else if 
do; 


/* connection. */ | connSt, 

/* response ptr */-:-respSmbox$t, 
/* status ptr */ @exSval); - 
iorsSt=rqSreceiveSmessage( 

/* mbox token */ “respSmboxst, 
/* time limit */. GEFFFFH, 

/* response ptr’ */ @dummyS$t 

/* status ptr */ ° cee 


call rq$deleteSsegment(iorsSt, geeeveity 

call rgq$deleteSmailbox(service$mboxSt,@ex$val) ; 
call rq$deleteSmailbox(resp$mboxSt, @exSval) ; 
req$Sseg.status=@; 

call rg$send$message ( 


/* mbox token */ outputSrequestSmboxSt, 
/* object token */ reqSsegSt, 

/* resp token */ O, | 

/* status ptr */ @exSval); 


call rqSdeleteStask(@,@exSval); 
req$seg.cmd=read then 


call rqSaSread ( 


*/*® connection */ ° connSt, 

/* buf ptr */ @reqSseg.buf, 
/* count */ req$seg.count, 

/* resp token */... resp$mboxSt, 
/* status ptr */ @exSval); 
iorsSt=rqSreceiveSmessage(. 

/* mbox.token */ . . resp$mboxSt, 
/* time limit */. @OFFFFH, 

/*® resp ptr */ - @dummySt, 

“f* status ptr */ . @exSval); 


call rqSdeleteSsegment(iors$t,@exSval) ; 
req$seg.status=0; 
call rg$ send$message ( 


f*®: mbox token */ a epee cannes caeeres. 
/* object token */ reqgSseg$t, 
-/* resp token */ a, 


end; 


else if 
do; 


/* status ptr */ —  @exSval); 


req$seg.cmd=write then. 


call ra$a$write( 


/*® connection */— connst, 

/* buf ptr: */ . @reqSseg.buf, 
/* count */ req$seg.count, 
/* resp token */ respS$mboxSt, 
/* status ptr */ . — @ex$val); 
iors$t=rqSreceiveSmessage( 

/* mbox token */ respSmboxSt, 
/* time limit */ Q@FFFFH, 

/* resp ptr */  @dummyst, 

/* status ptr */ @exSval);. 


call rqgSdelete$segment (iors$t,@exSval) ; 
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Module 2, continued 
292 4 call rq$sendSmessage( 
/* mbox token */ outputS$requestS$mboxSt, 
/* object token */ req$segSt, 
/* resp token */ 0, 
/* status ptr */ @exSval); 
293 4 end; 
end; /* of do forever */ 
295 2 end; /* of task */ 
296 1 end workerStask; 


MODULE INFORMATION: 


CODE AREA SIZE = §288H 648D 
CONSTANT AREA SIZE = #000H YD 
VARIABLE AREA SIZE = @@0@H OD 
MAXIMUM STACK SIZE = @¢34H 52D 


717 LINES READ 
@ PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 


2-105 AFN-01931A 


— AP-86: 


ISIS-II MCS-86 MACRO ASSEMBLER V2.9 ASSEMBLY OF. MODULE POINTR 


OBJECT MODULE PLACED IN 
ASSEMBLER INVOKED BY: 


LOC OBJ LINE 
i 
0004 2 
3 
---- 4 
---- 5 
6 
; 
on g 
9 
1g 

anno 1 ; 
12 
0882 55 i3 
0201 &BEC 14 
15 
6004 [] 16 
1,7 
0003 8E4604 18 
0096 33DB 19 
20 
21 
0888 SD 22 
0909 C2200 23 
24 
= 25 
26 


ASSEMBLY COMPLETE, 


ET pointr. asg6 debug pr (: £5:pointr.1st) 


4 > set args for “DELUXE" 


segment word public OEE | 


code 


cs:.cgroup 


near 

pointerize 

bp F ; Save 

bp, sp 7 mark stack 
word ptr [bp + ano. GEE + 1] 

es, token ; get —e 

joy arame si 4 ; zap offset 
sp, bp > restore stack 
bp 

2 


Module 3 
>:Fl: POINTR. OBJ 
asm8 6 
SOURCE: 
‘S$title(pointerize Utility) 
arg off equ 
code 
code ends 
cgroup group 
code segment 
assume 
pointerize proc 
public 
push 
mov 
token equ 
mov 
xor 
; mov 
pop 
ret 
pointerize endp 
code ends 
end 


NO ERRORS FOUND 
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Module 4 


ISIS-II PL/M-86 X167 COMPILATION OF MODULE LISTUTILITIESMODULE 
OBJECT MODULE PLACED IN :Fl:lstutl.OBJ 

COMPILER INVOKED BY: plm86 :Fl:lstutl.plm PRINT(:F5:LSTUTL. LST) 
DEBUG COMPACT OPTIMIZE(3) ROM DATE(3/7/8Q) 


15 
16 


NO NMNMNNNN ND NO 


NO 


~ 


NM NN DN NO 


listSutilitiesSmodule: 


do; 
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LISTSUTILITIES: PUBLIC PROCEDURES. 


This module contains three list manipulation utilities. 
InsertSonS$list takes the given node and inserts it on the 
list indicated by the root node parameter. DeleteSfrom 

list unlinks the indicated node from the list it is 

linked to. Search$list scans the list from the root looking 
for the indicated node. If found, the token for the node 

is returned. If not found, a zero is returned. 
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Sinclude(:£4:common.lit) 

SSAVE. NOLIST 

Sinclude(:fl:node.lit) 

/* literal declaration of node descriptor for list utilities */ 
Ssave nolist 

Sinclude(:fl:pointr.ext) 

/* external declaration of pointerize procedure */ 

Ssave nolist 


InsertSon$list: procedure( rootS$t,newSdescSt) reentrant public; 


end; 


declare ; 
(rootSt,newSdescSt,fwdSdesc$t) token, 
(rootSp,newSdescSp,fwd$desc$p) pointer, 
(root based root$p) node, 
(newSdesc based newSdescSp) node, 
(fwdSdesc based fwdSdescSp) node; 


rootSp=pointerize(rootSt) ; 
newSdescS$ p=pointerize(newSdescSt) ; 
fwdSdescSt=root.linkSf; 
fwdSdesc$p=pointerize(fwdSdescSt) ; 
root.linkSf=newSdescSt; 
newSdesc.linkSf=fwdSdescSt; 
newSdesc.linkSb=rootSt; 
fwdSdesc.linkSb=newSdescSt; 
return; 


/* insertSonSlist */ 


DeleteSfromSlist: procedure(desc$t) reentrant public; 


declare 
descS$t token, 
(descSp,bS$descS$p,f$descSp) pointer, 
(desc based descSp) node, 
(bSdesc based bSdescSp) node, 
(fS$desc based fSdescS$p) node; 


descSp=pointerize(descSt); 
bSdescS$ p=pointerize(desc.linkSb); 
fS$descS$ p=pointerize(desc.linkSf) ; 
bSdesc.linkSf=desc.linkSf£; 
fSdesc.linkSb=desc.linkSb; 
return; 
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Module 4, continued 
35 2 end; /* deleteSfromSlist */ 
36 ] searchSlist: procedure (root$t,WS$ID) word reentrant public; 


37 2 declare 2 
(rootSt,WSSID) word, 
is$desc$p,root$p) pointer, 
(root based rootS$p) node, 
(s$desc based s$desc$p) node, | 
s$descS$p$o structure (offset word, hase word) at(@s$descS$p), 
temp pointer; 


38 2 sSdesc$p=pointerize(rootS$t) ; 
39 2 nextSnode: . 
if s$desc.workS$stationSID=WSSID then 


40 2 return sSdesc$pS$o.base; 

41 2 if s$desc.linkSf = root$t then 
42 2 return @; 

43 2 temp=pointerize(s$desc.linkSf) ; 
44 2 sSdescS$p=temp; : 

45 2 goto nextS$node; 

46 2 end; /* searchSlist */ 

47 l end listSutilities$module; 


MODULE INFORMATION: 


CODE AREA SIZE = QAAFEH 254D 
CONSTANT AREA SIZE = APAAAH AD 
VARIABLE AREA SIZE = @@?@H iD 
MAXIMUM STACK SIZE = #@18H 24D 


114 LINES READ 
@ PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 
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ISIS-II PL/M-86 X167 COMPILATION OF MODULE STARTANDFINISH 
OBJECT MODULE PLACED IN :Fl:strfin.OBJ 

COMPILER INVOKED BY: plm86 :Fl:strfin.plm PRINT(:F5:STRFIN.LST) 
DEBUG COMPACT OPTIMIZE(2) ROM DATE (4/28/88) 


314 
S15 
316 


317 
318 


319 


329 


321 


NN fF 


StartSandSfinish: 
do; 
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INITS534$10 and FINISH$534$I0: PUBLIC PROCEDURES. 


This module contains the init$534SIO and the FINISHS534SI10 
procedures which can be called by the RMX/86 I/O system. STARTSIO 
is called just before the first attachSdevice is performed. 

It will create the interrupt task and the eight interruptSpending 
semaphores. The FINISHSIO procedure is called just after the 

last detachSdevice is performed. It undoes everything the STARTSIO 
call did. 
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Sinclude(:£4:nucprm.ext) 

SSAVE NOLIST 
Sinclude(:£4:common.lit) 

SSAVE NOLIST 
Sinclude(:f1:duib.lit) 

/* duib structure definition. * / 
Ssave nolist 
Sinclude(:f4:nerror.lit) 


SSAVE NOLIST 

Sinclude(:fl:pointr.ext) 

/* external declaration of pointerize proeeaure x / 

Ssave nolist 

Sinclude(:fl:retdta.lit) | 

/* literal declaration of retSdata structure for init$534Sio */ 
Ssave nolist 


init$534Shw: procedure(dataSp) external; 
declare dataSp pointer; 
end init$534Shw; /* initializes 534 hardware */ 


int$534Stask: procedure external; 
end int$534Stask; 


declare 
beginSintS$534Sdata byte external, 
IO$baseSaddr byte public, 
intS$level word public, 
gSretS$data$p pointer public, 
reqSmbox$St token public; 


init$534S1I0: procedure(duibSp,retSdata$t$p,statusS$p) reentrant public; 


declare 
(duibSp,retSdataStSp,statusSp) pointer, 
(duib based duibSp) devSunitSinfoSblock, 
(retSdataSt based ret$dataStS$p) token, 
(status based statusSp) word, 
devSinfoSp pointer, 
devSinfo based devSinfoSp structure ( 
level word, 
priority Buea: 
TOSbaseSaddr byte), 
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Module 5, continued 


exSval word, 

dataSsegSp pointer, 

dataSseg$p$o Ber Ge ave Coeeet word, base word) at(@dataS$segSp), © 
(i,j) byte; 


declare 
retSdataSp pointer, 
retSdata based retS$dataSp structure(retSdataSstruc) ; 


retSdataSt=rqScreateS$segment (size(retSdata) ,@exSval); 
if exSval <> @ then 

goto err@; 
gSretS$dataSp,retSdata$p=pointerize(retSdataSt) ; 
devSinfoS p=duib.devSinfoSp; 
lOSbaseSaddr,retSdata.IOSbase=devSinfo.I1O0ShaseS addr; 
intSlevel,retSdata.intSlevel=devSinfo.level; 


/* create the request mailbox */ 


retSdata.request$mbox$t,reqSmboxsSt 
=rgScreateSmailbox(#,@exSval); 
if exSval <> A then 
goto errl; 


retSdata.respSmboxSt=rq$createSmailbox(#,@exSval) ; 
if exSval <> @ then 
goto err2; /* clean up partial creation */ 


data$segS$ p=@begin$int$534Sdata; 
retSdata.intStaskS$t=rqScreateS task ( 
/* priority */ devSinfo.priority, 
/* entry point */ @intS534Stask, 
/* data segment */ dataSsegSpSo.base, 
/* stack pointer */ 4, 


/* stack size */ | AAG, 
/* task flags */ A, 
/* status pointer */ MexSval); 


if exSval <> @ then 
. goto err3; /* can't create. clean up partial creation */ 


do i= to 7; /* create semaphores */ 
retSdata.intSsema(i)=rqS$createS semaphore ( 
7/* initial value */ @, 


/* max value */ 1, 
/* priority queue */ ly 
/* status ptr */ @exSval); 


if exSval <> @ then 


goto err4; /* clean up partial creation */ 


end; 

call initS$S34Shw(retSdataSp) ; 
status=ESOK; 

return; 


err4: 
do j=@ to i; 
call rq$deleteSsemaphore(retSdata.intSsema(j) ,Status$p) ; 
end; 
call rgSresetSinterrupt(devSinfo.level,statusSp) ; 
err3: 
call raSdeleteSmailbox(retSdata.respSmbox$t,statussSp) ; 
err2: 
call rgqSdeleteSmailbox(retSdata.requestSmboxSt,statusSp) ; 
errl: 
call rqSdeleteSsegment (retSdataSt,status$p) ; 
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Module 5, continued 


355 2 erro: 
Status=exSval; /* restore original status condition */ 
356 2 return; 


357 2 end; /* of procedure */ 
358 il finish$534SI10: procedure(duibSp,retS$dataSt) reentrant public; 
359 2 declare 


duibSp pointer, 
devSinfoSp pointer, 
devSinfo based devSinfoSp structure( 
level word, 
priority byte, 
IOSbaseSaddr byte), 
retSdataSp pointer, 
retS$data based retSdataSp structure(retSdataSstruc) , 
(duib based duibSp) devSunitSinfoSblock, 
retSdataSt token, 
i byte, 
exSval word; 


369 2 devSinfoSp=duib.devSinfoSp; 
361 2 retSdataSp=pointerize(retSdataSt); 
362 2 call rgSresetSinterrupt(devSinfo.level ,@exSval) ; 
363 2 call roSdeleteSmailbox(ret$data.requestSmboxSt,@exSval) ; 
364 2 call rqSdeleteSmailbox(retSdata.respSmboxSt,@exSval) ; 
365 2 ao 120. to: 7 
366 3 call raqSdeleteSsemaphore ( 
retSdata.intSsema(i), 
@exSval); 
367 3 end; 
368 2 call ra$deleteSsegment (ret$datast,@exSval) ; 
369 2 return; 
370 2 end; /* of procedure */ 
She ] end startSandSfinish; 


MODULE INFORMATION: 


CODE AREA SIZE = @220H 544D 
CONSTANT AREA SIZE = @AMCH AT) 
VARIABLE AREA SIZE = AMMOH 9D 
MAXIMUM STACK SIZE = #344 52D 


671 LINES READ 
® PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 
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~ Module 6 


ISIS-II PL/M-86 X167 COMPILATION OF MODULE CUEUES oo ONORULP 
OBJECT MODULE PLACED IN :Fl:queio.OBJ 

COMPILER INVOKED BY: plm86 :Fl:queio.plm PRINT(:F5: QUETO. LST) 
DEBUG COMPACT OPTIMIZE(2) ROM DATE (4/25/88) 


315 
316 


317 


318 
319 


queue$534$io$module: 
do; 


III III IGG ICOIGCIGIGIIGI CIC OIC CIGICI ITI IK 


QUEUES534$10. PUBLIC PROCEDURE. 


This procedure is called by the. 1/0 System to queue 
an 1/0 request to the 534 board. The function. field 
in the IORS is used to determine what specific action 
to take. Module also contains a dummy cancel$534Sio 
procedure. 


HHHKKHKHKKKKEK KEKE KEKE KEKE KHIR EEE EEE KEK KEK KEKE KEKE KEK KKKERERRKEKEEKEEKEKE / 


Sinclude(:f£4:nucprm.ext) 
SSAVE NOLIST 
Sinclude(:£4:common. Lit) 
SSAVE NOLIST 
Sinclude(:f4:nerror.lit) 


SSAVE NOLIST 

Sinclude(:fl:pointr.ext) 

/* external declaration of pointerize procedure */ 
Ssave nolist 

Sinclude(:fl:duib.1lit) 

/* duib structure definition */ 

Ssave nolist 

Sinclude(:fl:iors.lit) 

7* literal declaration for iors */ 

S$save nolist 

Sinclude(:fl:retdta.lit) 

7* literal declaration of. retSdata Structure for init$534Sio */ 
Ssave nolist 


io$534Stask: procedure external; 
end io$534Stask; 


declare 
beginSioStask$data byte external; 


queue$534Sio: procedure(iors$t,duibSp,retS$dataSt) reentrant public; 


declare 
(iorsst, Petsaatast) token, 
dataS$segSp pointer, 
data$seg$p$o structure(offset word,base word) at(@data$segSp), 
IDDR literally '2AH', 
(duib$p,ret$data$p,iorss$p) pointer, 
(duib based duibSp) dev$unitSinfoS$block, 
(ret$data based ret$dataSp) structure(retS$dataSstruc) , 
(iors based iorsfp) TOSrequestSresultSsegment, 
joStaskSt token, 
unitSinfoSp pointer, 
unitSinfo based unitSinfoSp structure (. 
usart$cmd byte, 
haudSrate word), 
i byte, 
dummy$t token, 
exSval word; 
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3290 
321 


322 
3235 


324 


325 
326 
327 


328 
329 


330 
331 
332 


335 
334 


535 
336 
337 


338 
339 
348 


341 


342 
343 
344 


345 


346 
347 
348 
349 
358 
351 


So2 
3:03 
354 
355 


356 


No 


DB W 


Ot & & BW Dm mm W 


Or 


BHU S 


Module 6, continued 


iors$p=pointerize(iorsSt) ; 
retSdataS$p=pointerize(retS$dataSt) ; 


if iors.funct > 7 then 


goto badSrequest; 


do case iors.funct; 


do; /* case fi-- read */ 
iors.aux$p=retSdataSp; 
call raqSsendS$message( 


/* mbox */ retSdata.requestSmboxSt, 


/* token */ iorsSt, 
/* resp */ 6, 
/* status ptr*/ @exSval); 
return; 
end; 


do; /* case 1l-- write */ 
iors.auxSp=retSdataSp; 
call rqSsendS$message( 


/* mbox */ retSdata.requestSmboxSt, 


/* token */ iorsSt, 
/* resp */ @, 
/* status ptr*/ @exSval); 
return; 
end; 


ado; /* case 2--seek (illegal) */ 
goto badSrequest; 


end; 

do; /* case 3-- special (illegal) 
goto badSrequest; 

end; 

do; /* case 4-- attachSdevice */ 


/* create two I/O tasks */ 


wa 


dataSsegS$ p=@beginSIOStaskSdata; 


do i=@ to l; 


ioStaskS$t= rgqScreateStask ( 


/* priority */ 156, 


/* entry pnt */ @io$534S$task, 
/* data seg */ dataSsegSpSo.base, 


/* stack ptr */ 6G, 


/*® stack size */ 5008, 
/* task flags */ 0, 
/* status ptr */ @exSval); 


end; 


unitSinfoSp=duib.unitSinfoSp; 


do i=@ to 3; 


output (retSdata.usartScmdSport(iors.unit) )=@; 


end; 


output (retSdata.usartScmd$ port (iors.unit) )=49H; 
output (retSdata.usartScemdSport(iors.unit))= 


unitSinfo.usartSemd; 


output(retSdata.usartScmdSport(iors.unit) )=27H; 


output (retSdata.IOSbase+@CH) 


=(; 


/* select cntrl blk 


output (retS$data.timerScmdSport(iors.unit))= 
retSdata.timerScmd(iors.unit); 
output (retSdata. Eimer; t0a0o Pore tor. unit) )= 


low(unitSinfo.baudSrate) ; 


output (retSdata.timerSloadSport(iors.unit) )= 


high(unitSinfo.baudSrate) ; 
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Module 6, continued 
357 4 output(retSdata. TOSbase+BDH)=8; ce Sooo data blk */ 
7/* accept interrupt and character Eom receiver sh 


358 4 dummySt=rq$receiveSunits ( 7 
/* sema */ retSdata. enie acme 2 * iors.unit), 
/* units */ il, 7 - 
/*® timeSout / A, | 
Ls status */ @exSval); 


359 4 i=input(retSdata. a ee a oe iors.unit )); 
368 4 goto Okp ea aerese 
361 4 end; 
362 3 do; /* case 5-- detachSdevice */ 
/* send two copies of the detach request to the request mailbox. 
This will signal to two of the I/O tasks that they are to 
delete themselves */ 
363 4 call rqS$sendSmessage( 
/* mbox token */ retSdata. requestSmboxSt, 
/* object token */ iorsSt, 
/* response */ retSdata.respSmboxSt, 
/* status */ @exSval); 
364 4 dummySt=rq$receiveSmessagé( 
/* mbox token */ retSdata.respSmboxSt, 
/* timeSlimit */ OF FFFH, 
/* response ptr */ @dummySt, 
/* status ptr */ @exSval); 
365 4 call rq$sendSmessage( 
/* mbox token */ retSdata.requestSmboxSt, 
/* object token */ iorsSt, 
/* response */ retSdata.respSmboxSt, 
/* status */ @exSval); 
366 4 dummySt=rqsreceiveSmessage ( 
/* mbox token */ retSdata. respSmboxSt, 
/*® timeSlimit */ OFFFFH, . 
/* response ptr */ @dummySt, 
/* status ptr */ @exSval); 
367 4 goto okSsendSresp; 
368 4 end; 
369 3 do; /* case 6-- open */— 
370 4 | goto okSsendS$resp; 
371 4 end; 
372 3 do; /* case 7-- close */ 
373 4 goto okSsendSresp; 
374 4 end; 
375 3 end; /* do case */ 
376 2 return; 
377 2 badS request: 
iors.status=IDDR; 
378 2 goto sendSresp; 
379 2 okSsend$ resp: | 
iors. status= ESOK; 
382 2 sendSresp: 
call rgqSsend$message(iors.resp$mbox, jorsst, %,@exSval); 
381 2 return; 
382 2 end; /* pEoregure * f° 
383 1 cancel$534$io: Procedure(iorsst, eee Re retsdatast) public; 
384 2 declare’ 
(iorsst, ret$datast) token, 
duib$p- pointer; 
385 2 return; 
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Module 6, continued 
386 2 end; 
387 1 end queue$534SioSmodule; 
MODULE INFORMATION: 
CODE AREA SIZE = @28CH 5 24D 
CONSTANT AREA SIZE = @@80H AD 
VARIABLE AREA SIZE = §@006H AD 
MAXIMUM STACK SIZE = @@38H 56D 


729 LINES READ 
@ PROGRAM ERROR(/S) 


END OF PL/M-86 COMPILATION 
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Module 7. 


ISIS-II PL/M-86 V2.@ COMPILATION OF MODULE INTERRUPT534MODULE 
OBJECT MODULE PLACED IN :F1l:int534. OBJ 

COMPILER INVOKED BY: pim86 :Fl:int534.plm PRINT(: Fl: INT534. LST) 
DEBUG COMPACT OPTIMIZE(2) ROM DATE(5/28/88) 


Snointvector 
l Interrupt$534Smodule: 
do; 


AAI III IOITIGCIIOCII GIGI ICC TOTO TOT TIT ITT 


INTS534STASK and INTS534SHND: 
PUBLIC PROCEDURES: 


This module contains the interrupt handler and the interrupt 
task for the 534 board interrupt. The handler simply calls 
signal$interrupt and the task reads the ISR on the 534 
board's 8259 and sends a unit to one of eight interrupt$ 
pending semaphores to signal the occurrence of the event. 


KIKI IKE IKKE REE HEEIGKEKAAEEIK EE REAREA RE KERE EEE EKREKEKEEEEKEREEEKEEE / 


Sinclude(:f2:nucprm.ext) 

SSAVE NOLIST 

Sinclude(:fl:retdta.lit) | 

/* literal declaration of ret$data structure for init$534Sio */ 
Ssave nolist 

Sinclude(:f2:common.1lit) 

SSAVE NOLIST 


308 1 declare 
begin$int$534$data byte public, 
g$ret$data$p pointer external, 
IOSbaseSaddr byte external, 
intS$level word external; 


309 1 int$534$hnd: procedure interrupt 5; 


319 2 declare 
1 word, 


ex$val word; 


311 2 l=rqSget$level (@exSval) ; 
312 2 call rq$signalSinterrupt(1,@exSval) ; 
313 2 return; 
314 2 end; 
315 1 int$534$task: procedure reentrant public; 
316 2 declare 
i I10$534Sbase byte, 
int$534Slevel word, 
ret$dataSp pointer, 
ret$data based ret$data$p structure(ret$data$struc) , 
cS$level byte, 
ex$Sval word, 
eoi literally '20H'; 
317 2 I10$534Sbase=lI0SbaseS addr; 
318 2 intS534Slevel=intSlevel; 
319 2 retSdataSp=gSretS$dataSp; 
320 2 call rgSsetSinterrupt ( 
/* level */ tenes 
/* flags */ 


/* entry point ys interruptSptr (int$534$hnd) , 
/* data segment */ 6, | 
/* status ptr */ @exSval); 


2-116 AFN-01931A 


AP-86 


321 
322 
323 
324 
325 
326 
327 
328 


329 
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Module 7, continued 


do forever; | 
call rqswaitSinterrupt(int$534Slevel, @exSval); - 
output (10$534Sbase+8) =@CH; 
cSlevel= input (10$534$base+8) and @7H; 
call rq$sendSunits(ret$data.int$sema(c$level) ,1,@ex$val) ; 
output (10$534Sbase+8) =EOI; 

end; /* of do forever */ 

end; /* of procedure */ 


end interrupt$534Smodule; 


MODULE INFORMATION: 


CODE AREA SIZE = QB5H 181D 
CONSTANT AREA SIZE = @@0@H 8D 
VARIABLE AREA SIZE = @@05H 5D 
MAXIMUM STACK SIZE = @@26H 38D 


541 LINES READ 
@ PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 
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ISIS-II PL/M-86 X167 COMPILATION OF MODULE TOS34TASKMODULE 
OBJECT MODULE PLACED IN :Fl:iotask.OBJ 

COMPILER INVOKED BY: plm86 :Fl:iotask.plm- PRINT (: ES: IOTASK. LST) 
DEBUG COMPACT ORT ness) ROM DATE (4/25/88) | 


1 


314 


315 
316 


sly 
318 


319 
329 
321 


1 


2 


W W 


ey ee ee 
do; 


J RRR KERR RE RRR EEE ERR KEE REI EKER KEE KR KEKE REE REKERREKERKEEKEKRKKER 


IOSS34STASK: TASK. 


This task receives IORS segments from the queuesio 
procedure and performs the necessary input or 
output operations on the iSBC 534 board. 


HRI RIK RRR RR RIK RR IRR RR RRR IRR RAR RRR RRR KERRIER RRR ERR IRIE KIRK / 


Sinclude(:f£4:common.lit) 

SSAVE NOLIST 

Sinclude(:f1l:pointr.ext) 

/* external declaration of pointerize procedure */ 
Ssave nolist 

Sinclude(:f4:nucprm.ext) 

SSAVE NOLIST 

Sinclude(:f4:nerror.lit) 


SSAVE NOLIST 

Sinclude(:fl:retdta.lit) 

/* literal declaration of retS$data structure for init$534Sio */ 
Ssave nolist 

Sinclude(:fl:iors.lit) 

/* literal declaration for iors */ 

Ssave nolist 


declare 
begin$ioS$taskS$data byte public, 
reqSmbox$t token external, 
fS$detach$device literally '5', 
fSread literally '@', 
fSwrite literally 'l'; 


TO0$534Stask: procedure reentrant public; 


declare 
iors$t token, 
iors$p pointer, 
iors based iors$p IO0SrequestSresult$segment, 
exSval word, 
respSt token, 
buff£$p pointer, 
buf based buffS$p (1) byte, 
i word, 
unit byte, 
ret$data$p pointer, 
retSdata based retSdataSp structure(retS$dataS$struc) , 
c$val word; 


do forever; 
lorsSt=rq$receiveSmessage(regq$mboxSt,OFFFFH,@resp$t,@ex$val); 


/* check for non-existence of mailbox. IF last device has been detached 
the mailbox will be deleted In this case, delete thyself */ 


if ex$val= ESexist then 


call rqSdeleteStask(%,@exS$val) ; 
iorsSp=pointerize(iorsS$t); 
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and @7FH; 


Module 8, continued 
322 3 buffSp=iors.buff$p; 
323 3 unit=iors.unit; 
324 3 iorsS.actual=9; 
325 3 i=@; 
326 3 retSdataSp=iors.aux$p; 
327 3 if iors.funct = f$detachSdevice then 
328 3 do; 
329 . .4 | call rg$sendSmessage( 
/* mbox token */ respsSt, 
/* object token */ iorsSt, 
/* response token */ 0, 
/* status ptr */  . @exSval); 
330 4 call rq$deleteStask(@,@exSval) ; 
331 4 | end; 
332 a if .iors.funct= fSread then 
333 3 do while iors.count >@; 
334 4 cSval=rq$receiveSunits ( 
/* sema */ retSdata.intSsema(2*unit), 
/* units */ 1, 
/* time */ @FFFFH, 
/* status*/ @exSval); 
335 4 buf (i) =input(retSdata.usartSdataS port (unit) ) 
33604 i=itl; 
337 4 iors.count=iors.count-1l; 
338 4 iors.actual=iors.actual+l; 
339 4 end; 
340 3 else if iors.funct= fSwrite then 
34] 3 do while iorS.count >@; 
342 4 c$val=rqSreceiveSunits ( 
/* sema */ retSdata.intSsema(2*unit+l), 
/* units */ 1, 
/* time */ AFFFFH, 
f® status*/ @exS$val); 
343 4 output (retSdata. Wear esda tamer (antes buf (i); 
344 4 i=i+l; 
345 4 -lors.count=iors.count-l; 
346 4 iors.actual=iors.actual+l; 
347 4 end; 
lors.status=ESOK; 
349 3 iors.done=TRUE; 
350 3 call ra$send$message(iors. respSmbox,iorsSt,@, @ex$val); 
351 3 : end; /* of do forever */ 
352 2 end; /* of procedure */ 
353 1 end io$5S34Stask$module; 


MODULE INFORMATION: 


CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
624 LINES READ 
@ PROGRAM ERROR(S) 


END OF PL/M-86 COMPILATION 


§18DH 


BOOWH 
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1D 

46D 
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ISIS-II PL/M-86 X167 COMPILATION OF MODULE INIT534HW 


-Module 9 | 


OBJECT MODULE PLACED IN :Fl:inithw. OBJ 
COMPILER INVOKED BY: plm86 :Fl:inithw.plm PRINT(:F5: -INITHW. LST) 
DEBUG COMPACT OPTIMIZE(2) ROM DATE (4/25/86) | 


1 


12 


13 
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init$534Shw: 
do; 


J RRR EK ERK ER REE RRR RRR KER ERE KEKE EE KEEKEEEKEKAKKEKK 


init$534Shw: PUBLIC PROCEDURE. 


This procedure initializes the iSBC 534 hardware and 
sets up the device dependent fields of the retS$data 
segment which will be used by the queueSio procedures. 


HHKKRKKKEKKRKEKEKEKRKEKEKREEKREKKKEEEKRKEERKEEKREREEEKER EKER KEKE KE REE EREREEEEEEEKE / 


Sinclude(:£4:common.lit) 


S$SAVE NOLIST 


Sinclude(:fl:retdta.lit) 


7/* literal declaration of ret$data structure for init$534Sio */ 


Ssave nolist 


init$534Shw: procedure(ret$data$p) 


declare 


retS$dataSp pointer, 


reentrant public; 


retS$data based retS$data$p structure(retSdataS$struc) , 


(base,i) byte; 


base=retSdata.ioS$base; 


output (base+OFH)=0; /* 


output (base+@DH)=0; /* 
output (base+8)=16H; /* 


output (base+9) =f; /* 


output (base+9) =@; /* 


/* attachSdevice calls will 


board reset 
select data 
output ICWl 
output ICW2 
output mask 


initialize 


/* set up tables of port addresses for 


retSdata.timerScmd(f), 


retSdata.timerScmd(1)=76H; 
retSdata.timerScmd(2)= OB 6H; 


do i=@ to 3; 


is 

block */ 
«7, 

*7] 

word */ 


usarts and timers */ 
use by queueSio procs */ 


retSdata. pameroemats)= 36H; 


retS$data. usartScmd$port(i)=base+2*i+1; 
retSdata.usartS$dataSport(i)=base+2*i; 
retSdata.timerS loadSport(i)=baseti; 


end; 


retSdata.timerS loadSport(3)=base+4; 


retSdata.timerScmdSport(@), 
retSdata.timerScmdSport(l), 
retSdata.timerScmdS$port(2)=base+3; 
retSdata.timerScmdS port (3)=base+7; 


return; 


end; 


end init$534Shw; 


MODULE INFORMATION: 


CODE AREA SIZE = OE 4H 
CONSTANT AREA SIZE = @@OOH 
VARIABLE AREA SIZE = @@0@H 
MAXIMUM STACK SIZE = @@@8H 


77 LINES READ 
@ PROGRAM ERROR (S) 


END OF PL/M-86 COMPILATION 
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FREE 
SPACE 
ROOT 
JOB 
APPLICATION 
JOB 


COMMUNICATIONS 
JOB 
0 SYSTEM 
NUCLEUS 
INTERRUPT VECTOR 


System Memory Map 


kok kK Rk RK OU NNUCLNK.LCSD)  —-— 8 FF LK 


THIS SUBMIT FILE LINKS THE NUCLEUS. 


me me SO Be RO 


:F@:LINK86 & 
:F1l:NUC86.LIB(NENTRY), & 


:F1l:NUC86.LIB & 
TO :Fl:NUCLUS.LNK MAP PRINT(:F1l:NUCLUS.MP1) NAME(NUCLEUS) 


kok KK KL KL RL RL RL KKK CU NNUCLOC.CSD | —-- — *# — ¥ — FR KK 


THIS SUBMIT FILE LOCATES THE NUCLEUS IN MEMORY. 


me Te Me VE We Re Ne 


:F@:LOC86 & 

:Fl:NUCLUS.LNK TO :F1l:NUCLUS MAP PRINT(:F1l:NUCLUS.MP2) SC(3) & 
RESERVE (0 TO 7FFH) SEGSIZE(STACK(@)) & 

ORDER (CLASSES (CODE, DATA, STACK,MEMORY)) & 
OBJECTCONTROLS (NOLINES, NOCOMMENTS, NOPUBLICS, NOS YMBOLS ) 


Nucleus Link and Locate Commands 
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ios(date,origin) on 
Sample I/O System .csd file to link and locate an I/O System. 


This file links an I/O System with the timer included. 


This .csd file assumes the I/O System configuration module is 
iocnfg.a86 (found on the release diskette). 


The origin parameter sets the low address of the I/O System; 
all the segments are contiguous in memory. 


e 
‘ 
° 
a 
e 
a 
° 
c 
° 
’ 
e 
a 
° 
a 
° 
‘ 
° 
a 
e 
Ul 
° 
tf 


asm86 :fl:iocnfg.a86 date(%QO) 
1ink86 & 
:fls:ios.lib(ioinit), & 
:fl:iocnfg.obj, & 
:flsios.lib, & 
ffs r pife.d 1b & 
to :fl:ios.ink map print(:fl:ios.mp1) 
loc86 :fl:ios.lnk to :fl:ios map sc(3) print(:fl:iosS.mp2) & 
oc(noli,nopl,nocm,nosb) & 
order(classes(code,data,stack,memory)) & 


addresses(classes(code(%l))) & 
segsize(stack(@)) 


1/O System Link and Locate Commands 


Submit file to generate located version of file transaction job 


k86 & 
:f1:ftinit.obj, 
:fl:listen.obj, 
:fl:worker.obj, 
:fl:pointr.obj, 
:flsrpifc.lib 
to :flsapexl.ink map print(:fl:apexl.mp1). 


! 
loc86 :fl:apexl.ink to :fl:apexl map sc(3) print(:fl:apexl.mp2) & 
oc(noli,nopl,nocm,nosb) & 
order(classes(code,data,stack,memory)) & 
addresses (classes(code(%l))) & 
segsize(stack(@)) 


File Transaction Job; Link and Locate Commands 


Submit file to generate located version of communications job 


ink86 & 
:flscminit.obj, & 
:£flscomm.lib, & 
:fl:pointr.obj, & 


:fl:rpifc.lib & 
to :£l:comm.ink map print(:fl:apexl.mpl) 
loc86 :fl:comm.ink to :f£1l:comm map sc(3) print (:£l:comm. mp2) & 
oc(noli,nopl,nocm,nosb) & 
order (classes (code, data,stack,memory)) & 
addresses(classes(code(#1) )) & 
segsize(stack(@)) 


Communications Job; Link and Locate Commands 
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877EH 
877EH 
877EH 


—& 077EH 
Q77EH 


®83EH 


16E 4H 


_@EB3H 


OCA8H 


073EH 


SEGMENT MAP 


START 


877EOH 
14540H 
14600H 
—P 146EGH 
14746H 
14756H 
—P 14756H 


1475H @79EH PUB’ SETUP544, 


1475H 


STOP 


1453EH 
145FFH 
146DFH 
14745H 
14746H 
14756H 
1475@H 


INITDEVICETABLES 
DECRUSECOUNT 
NAMEDC HANGEACCES 


ATTACHDEVICETASK _ 
ROAIOSINITTASK . — 


Q77EH 


O77EH 


LENGTH ALIGN NAME | 


CD5FH 
BOC OH 
OBE OH 
G866H 
GHOBH 
GOOOH 
ZO0GH 


CODE 
REQ TABLE 
IOS TABLE 
DATA 
STACK 
??SEG 
MEMORY | 


Locate Map for I/O System 


077EH 
877EH 


Q77EH. 


OF BCH 
GE51H 
0B5AH 


05748 


OOK6H 


PUB 


PUB | 


PUB 


PUB 


PUB 


CLASS . 


CODE | 
CODE 

. CODE 
DATA 
STACK 


MEMORY. 


NAMEDDELETE 
UNLINKCONN 
ATTACHNAMEDF ILE 


- TLLEGALFUNCT 
_ COPYRIGHT. 


(The ‘““—® ” indicates entries for job macros and memory map) 


@5B5H PUB 


SEGMENT MAP 


START 


14756H 
— 15BDOH 
17@D2H 
17130H 
—P17130H 


STOP 


15BCDH 
1 79D 2H 
1712EH 
17130H 
17130H 


Locate Map for Communications Job . 


—p1713H 6112H PUB 
SEGMENT MAP 
START STOP 
17136H  17D59H 
17D68H 17E28H 
17E30H 17E9AH 


INDEX 


~1475H-. 


—P— 1475H 


LENGTH ALIGN NAME 


147DH 


1502H _ 
O04CH 


G00CH 


OOOOH © 


CODE 
DATA 


STACK | 


??SEG 
MEMORY © 


17D6H 63B5H PUB BEGINLISTENERTASKDATA1713H > 
INITTASKENTRY 


LENGTH ALIGN NAME 


GC29H 
@9C 8H 
OA6AH 


CODE 
DATA 
STACK 


1713H 


@6C5H PUB PACKETINPUT 


9572H 


PUB COMMINITTASKENTRY 
-ESS 


CLASS 


CODE 
DATA 
STACK 


MEMORY ~ 


9153H 
@491H PUB 


CLASS 


~ CODE 
‘DATA 
STACK 


Locate Map for File Transaction Job. 
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Macro call: SYSTEM (system parameters) 


Number of calls required: exactly one 


CONFIGURATION FILE NAME 


FORMAT: 


suggested 
parameter type default 


%SYSTEM (nucleus__entry, base 

rod__size, word (0) 

min__trans__size, work (64) 

debugger, see note (A) 
1 

default__e__h__provided, see note (N) 
2 

mode) word 


Valid entries for the debugger parameter include: 


A Debugger available 
N No debugger available 


Valid entries for the default__e__h__provided parameter include: | 


Y Yes 
D Debugger 
N No 


%SYSTEM Macro Worksheet 
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Macro call: SAB (for system address blocks) 


Number of calls required: one or more 


CONFIGURATION FILE NAME: APEX1 


FORMAT: 


-. suggested 
parameter co type default . 


%SAB 7 (start__base, 5 ae base 
ate end__base, | base 
type) : see hote 
| 1 


NOTES: 


1. The type parameter is reserved for future use. Enter 
the character U for this parameter. 


2. ASABiIS deciared between start__base:0 and end__base:F, inciusive. 


-%SAB Macro Worksheet 
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Macro call: JOB (defines first-level jobs) 


Number of calls required: one for each first-level job 


CONFIGURATION FILE NAME: APEX 1 


FORMAT: 


suggested | 
parameter type default 


(directory__size, word (0) 

pool__min, | word 

pool__max, word a (OFFFFH) 

max__objects, word 

max__tasks, word 

max__job__priority, | | byte | 129 
exception__handler__entry, addr ; 0:0 
exception__handler__mode, byte 1 
job_flags, — word 0 = | eee 
init__task__priority, byte | 1713:112 
data_segment_ base, base 

stack__pointer, > 4 ~ addr 

stack__size, word 

task__flags) word 


addr is specified as base:offset 


%JOB Macro Worksheet 
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sab(0,1998,U) 


$job(@,300h,@FFFh,#fff£FH,O£FfL£Lh,0,0:6,0,20, 128, 77e:3e,146e,8:80,512,@) 
$job(9,1FFH, OFFFH, OFFFFH, OFFFFH, 128, 0:0,0,9, 131 1475:572, 15bd, G:0,400,@) 
$job(@, 300H, OFFFFH, OFFFFH, OFFFFH, 128, 0:0,1,8,138, 1713: 112, th GGe 0:8, 480H,0) 
$system(88@,10,64,N,N,1) | 


Configuration File Apex 1.CNF 


a a a ee ee a or CTABLE.CSD ——*—*—*— *— k— kk kK KL 
; SUBMIT :Fx:CTABLE( fsys, fin, fout, config file, date ) 

: | 

; This submit file assembles the CTABLE module, where: 

: fsys = the system disk containing ASM86 

; fin = the source/input disk (Fl is assumed) 
pee” out = the object/listing/output disk 

- _ config file = the path-name of the configuration file 
oe date = the date 

es 

copy %3 to :fl:config.cnf b 


:$0:asm86 :%l:ctable.a86 pr(:%2:ctable.lst) oj(:%2:ctable.obj) date(%4) & 
xre€£. ogee ep 


Submit File to Generate Configuration Table | | 


=e 


+ kk kK RL RL kL KK CLNKRI.CSD --#—*-*# kk LL 


SUBMIT :Fx:CLNKRJ( fsys, fin, fout ) 


This submit file links the Root-Job, where: 
fsys the system disk containing LINK86 
fin the source/input disk 
fout the object/listing/output disk 


me 8 ™e MO TO MO MO MO NO MO NO 


2:30:link86 :%l:croot.lib(root) ;& 
2:%$2:ctable.obj,& 
:%¥l:croot.lib & 

:$2:rootjb.ink map pr(:%2:rootjb.mpl) 


Submit File to Link the Root Job 


» 
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me 


ok kk kL KL RL KL RE 6CLOCRILCSD —-—-*—*—*— *— kk 


SUBMIT :Fx:CLOCRJ( fsys, fin, fout ) 


This submit file locates the Root-Job, where: 


fsys = the system disk containing LOC&6 
fin = source/input disk 
fout = object/listing/output disk 


-- NOTE: BE SURE TO REPLACE THE "?????" BELOW WITH THE APPROPRIATE 
-~- ADDRESS THE ROOT-JOB IS TO BE LOCATED AT!! 


me Te me Te We Me We MWe WS Ne Be ~ 


2%$B8:loc86 :%2:rootjb.lnk to :%2:rootjb & 
map pr(:%2:rootjb.mp2) sc(3) & 

name(ROOT JOB) oc(nocm,noli,nopl,nosb) & 
segsize(stack(2@@h)) & 

order (classes(data,stack,memory,code)) & 
addresses(classes(data(12CQ@@H)) ) 


Submit File to Locate Root Job 
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l. INTRODUCTION 


As computer systems become more complex, a recurring 
need occurs to use multiple processing units. Multiproc- 
essing can, in many applications, increase throughput, 
enhance reliability, or create a more modular design ap- 
proach. Intel’s single board computer family provides a 
convenient tool for creating a multiprocessing environ- 
ment when combined with the Multibus system bus 
architecture. The use of the Intel RMX/80 Real-Time 
Multitasking Executive simplifies the creation of modu- 
lar designed system architectures. It also allows more 
efficient use of the processor’s capabilities by sharing 
them between several independent tasks. 


This application note provides insight as to the tech- 
niques which can be used to create a multiprocessing 
system which is fully compatible with the use of Intel’s 
RMX/80 multitasking executive. Both hardware and 
software capabilities of the Intel single board computers 
are discussed. For example, an explanation of both 
serial and parallel priority resolution techniques for 
creating a multimaster system are included. The tech- 
niques for using the bus lock features to provide mutual 
exclusion of resources and for creating both hardware 
and software semaphores is also a part of the applica- 
tion note. Many of the multiprocessing principles are 
combined to create the capability of transferring mes- 
sages between tasks operating on different processor 
boards, thus creating a combined multiprocessor/multi- 
tasking operating system. 


A potentially complex application is examined and the 


benefits gained by using a multiprocessing approach are — 


discussed. The various requirements defined from the 
application are used to demonstrate the available fea- 
tures of the Intel product line as applied to multi- 
processing. 


Extensions of the features are developed where neces- 


sary to create a complete solution to the design exercise. 
For example, a capability is provided for a flexible oper- 
ator interface to the system which provides certain 
global functions to the multiple processors. This capa- 
bility, called the Common System Module (CSM), in- 
cludes the required drivers for disk drives and for an 
operator’s CRT terminal. The operator interface in- 
cludes a BASIC interpreter capability. 


Finally, the application is modularized and the tech- 


niques which make the control solution easily imple-. © 
mented using multiprocessing techniques are demon- . 


strated. 


It is assumed that the reader has a furidamental knowl- 


edge of multitasking operating system concepts and is. 


familiar with the use of PL/M-80 as a language on 


Intel’s single board computers. In addition, a working — 


knowledge of BASIC is assumed. The reader not having 
these skills should refer to the documents referenced in 


the Related Publications section of this application — 


note. 


Multiprocessing Strengths 


The most common use of multiprocessing is to offload a 
main processor of low level duties in order to increase 
system throughput. Significant examples of this tech- 
nique are the use of Intel UPI devices such as the 8741A 
and the use of intelligent slave boards such as the Intel 
iSBC 544 Intelligent Communications Controller or the 
iISBC 569 Intelligent Digital Controller. The techniques 
which are developed in this application note do not 
apply to these multiprocessor implementations because 
they have been extensively covered in other application 
notes. 


Processors can be offloaded of other than low level 
functions in complex systems. Just as a real-time appli- 
cation can be divided into functional tasks, these tasks 
can be grouped according to function. Each function or 
class of tasks can be assigned to a single board com- 
puter. The system throughput can thus be increased 
since tasks can now run concurrently and, using the 
software precedures developed in this application note, 
can communicate among themselves as though they 
were operating on the same processor board. Single 
board computers operating in this manner are known as 
multimaster computers. 


A second instance where multiprocessing can be con- 
sidered in a system design is in those cases where the 
operational integrity can be enhanced by having more 
than one processor. In these cases, the application may 
require that no single component failure can completely 


- cause the system to fail. Multiprocessing provides this 


feature by allowing control of those operations associ- 


‘ated with a processor board to continue to function even 


when another board has failed. In many cases, provi- 
sion can be made to have the remaining board or boards 
take over some or all of the functions which were associ- 


ated with the failed board. Even though this would 


result in slower throughput, critical functions would still 
be performed by the computer system. 


Another benefit is the modular system design and ex- 
pansion capabilities which can be realized by using 
multiprocessing in industrial ‘control applications. Here, 
it has been found that process definitions and opera- 
tions tend to be rather dynamic. As products are im- 
proved or new ones added to the operation, the control 
system must be capable of being updated to conform to 
the new product flow. It is common to have an added. 


- requirement that the changes in a process must be made 


with no impact on other processes being controlled by 
the same system. Using a multimaster board for each 


process allows this operation to be easily implemented. 


Process Example 


~ To emphasize the advantages which can be gained using 
multiprocessing, consider the chemical production facil- 


ity whose process flow is shown in Figure 1. This prod- 
uct flow chart is typical of many found in the chemical 


: industry where a product is manufactured from several 
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raw ingredients which.are purchased. This type of:prod- 


uct lends itself well to automation. Consider, then, the 


approach to designing a control system which will oper- 


ate in the: facility which has been defined. 


The first. design goal iS to define siobal susieii tasks 
which need.to be performed by the system. Examination 
of the flow diagram in Figure 1 Paueht lead one = to define 
the: system tasks as: ie a; 


1) Inventory control _ 

2) Quality control ' 

3) Production scheduling | 

4) Weighing ingredients 

5) Mixing ingredients . 
6) Drying and forming. proguct 
7) Packaging © 


The choice just made certainly is. not the only valid pos- 
| sibility but it should be adequate to allow the design dis- 
cussion to continue. : 


The’'system tasks listed can be grouped according to 
supervisory and control tasks. Items 1 through 3 fall 
into the supervisory category and items 4 through 7 
belong to control category. This breakdown also groups 


QUALITY 


CONTROL 


WEIGH OUT 


the items according to the type of programs which will 
be required to implement the functions. 


The grouping of system functions into. categories sug- 
gests.that a multimaster approach is a good design path. 
to create a system solution. Five multimaster boards are. 
suggested, one for the supervisor and four boards which 
provide the control capabilities. This functional group- 
ing is seen in Figure 2. .. 


The examination of the product flow and system inter- 
actions shown in Figure 1 indicate that extensive com- 
munications are required between the various boards of 
the system. In addition, several tasks are required on 
each multimaster board and communications are re- 
quired between these tasks. 3 


Intel’s RMX/80 Real-Time Multitasking Executive: pro- 
vides a simple method of handling the on-board com- 
munication operations by supporting the transmission 
and receipt of messages: for data communication and 
synchronization. After’ a discussion of the hardware 
features which support multiprocessing, the application 


‘note will deal with the extension of the RMX/80 nucleus 


to support the transmission of messages between tasks 
which reside on different single board computers. 


DRY & FORM INTERMEDIATE 
| | PRODUCT STORAGE — 


ees MIX 
SAC EBIATS CORRECT INGREDIENTS 
MATERIALS — FORMULA | TOGETHER 
“Ss | ee ger 
~ eel 
a, “ | yw “7 
ar Se oa Be 
i. BS 7 “ 
: ; aa! “7 


SHIPPING _ 


PRODUCTION 
SCHEDULING 


1 PACKAGING 


Figure 1. Chemical Production Flow 
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MULTIMASTER |: 
BOARD 


MULTIMASTER 
BOARD 


DRY & FORM. 


MULTIMASTER 
BOARD 


PACKAGING MIXING 
MULTIMASTER 
BOARD 


’ MULTIMASTER 
BOARD 


MULTIBUS™ COMPATIBLE SYSTEM CHASSIS 


Figure.2. Multimaster System Solution 
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ll, MULTIBUS™ MULTITASKING 
OPERATIONS 


The interactions of the various multimaster board func- 
tions occur via the medium of the Multibus system bus. 
This bus structure is designed to easily support the use 
of more than one master processor in a system. Subse- 
quent paragraphs explain in some detail the features of 
the Multibus system bus which allow multimaster opera- 
tions when used with multimaster compatible single 
board computers. 


Bus Priority Resolution Lines 


The Multibus system bus uses seven control lines to sup- 
port the bus priority resolution techniques. Before con- 
tinuing with a discussion of these techniques, the reader 
should be provided with a definition of these lines and 
their functions. These lines are defined in subsequent 
paragraphs... One line is used for the system clock. It is: 


BCLK/ Bus Clock; the negative edge of BCLK/ is used 

to synchronize bus priority resolution circuits. 

BCLK/ is asynchronous to the CPU clock. It 

has a 100 ns minimum period and a 35 to 65 
percent duty cycle. 


All Intel single board computers which are capable of 
being used as a bus master can provide this clock signal. 
In a multiple processor application, it is necessary to 
select only one board which is to actually supply this sig- 
nal to the system bus. On all other processor boards, 
this signal must be disabled by removing the jumpers as 
indicated in the appropriate Hardware Reference Man- 
ual (HRM). 


Several bus signals are dedicated to providing informa- 
tion as to the status of the bus to processors which are 
attempting to obtain control for their own data transfer. 
These are defined to be: 


BPRN/ Bus Priority In Signal; indicates to a request- 


ing bus master board that no higher priority 


board is requesting use of the system bus. 
BPRN/ is synchronized with BCLK/. The sig- 
nal is not bused on the backplane and must be 
generated and connected by the user as will be 
seen. 


BUSY/ Bus Busy Signal; an open collector line driven 
by the current bus master to indicate that the 
bus is currently in use. BUSY/ prevents all 
other potential masters from gaining control 
of the bus. BUSY/ is synchronized with 
BCLK/. 


CBRQ/ Common Bus Request; an open-collector line 
which is driven by all potential bus masters and 
is used to inform the current bus master that 
another device wishes to use the bus. If 
CBRQ/ is high, it indicates to the current bus 
master that no other master is requesting the 
bus, and therefore, the present master can re- 


tain the bus control. This saves the bus: ex-.. 


change overhead which would be required to. 
release and again re-acquire control of the bus. 


The timing relationship of these signals can be seen in 
Figure 3. Note that some type of bus request signal is 
generated by the master wishing to assert control of the 
system bus. Through some type of logic, a determina- 
tion must be made as to the effect that the requesting 
master has the highest priority. If so, the logic informs 
the requesting master by setting the BPRN/ signal low. 


Tepm 


—|— 


BCLK/ | | | | | | | | | 


REQUEST/ | 
BPRN/ | 


Figure 3. Bus Master Request Timing 


Two signals are generated by single board products 
designed to be bus masters. These signals are used to 
generate the request signal. The request lines provided 
are known as: 


BPRO/ Bus Priority Out Signal; used with serial bus 
priority resolution schemes. BPRO/ is passed 
to the BPRN/ input of the master module with 
the next lower priority. BPRO/ is synchro- 
nized with BCLK/ and is not bused on the 
backplane. 


BREQ/ Bus Request Signal; used with a parallel bus 
priority network to indicate that a particular 
master board requires the use of the bus for 
one or more data transfers. BREQ/ is synchro- 
nized with BCLK/. It is not bused on the back- 
plane. 


The most easily implemented technique for supporting 
bus priority resolution is the serial or the daisy chain 
method. In this method, each board examines its 
BPRN/ line. If the line is low and the master desires to 
use the system bus, it may do so. Internal board logic 
then places the BPRO/ line high to inhibit boards along 
the daisy chain with lower priority from gaining control. 
Any board in the chain with its BPRN/ line high or 
which is requesting priority will set the BPRO/ line 
high. The wiring technique and logic of the serial prior- 
ity resolution scheme is shown in Figure 4. As long as 
the worst case propagation delay time between the high- 
est and the lowest potential bus master does not exceed 
30 ns, the technique provides a simple and effective 
method for resolving bus contention problems. Because 
of logic delays on iSBC boards, it has been found that 
the serial technique can only be used for a maximum of 
three bus masters when using a 100 ns clock rate. If 
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more masters are desired, either the clock must be | 


slowed or the priority resolution technique must be 
modified. Thus, the BREQ/ line is used to aUPpON the 
second or parallel priority scheme. 


oe a parallel priority network, all requests from bus 
masters are supported in parallel logic. Each master 
desiring use of the system bus places its BREQ/ line toa 
logical low condition. A parallel priority encoder chip 
such as a 74148 can be used to indicate the requestor 
having the highest priority. The output of the encoder 


can next be fed into a decoder network (748138) to gen-. 
erate a unique enable signal back to the processor 


board. These signals are fed back to the requesting 
boards as the BPRN/ control line. The logic to perform 
this parallel resolution is not a part of current Intel 
Multibus backplanes, so it must, when required, be con- 
structed and supplied by the user. Figure 5 shows an 
implementation which can be used to support a twelve- 
slot cardcage such as can be obtained using the Intel 
iCS-80 chassis. Since all bus priority requests are 
handled using parallel logic, additional potential bus 
masters may be added without adding to the signal delay 
time. Thus, the number of requests which may be re- 
solved is limited only by the number of available card 
slots on the Multibus system bus. ; 


HIGHEST PRIORITY 
iSBC™ BOARD 


> 
= 
c 
° 
jem 
a. 
) 
_ = 
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c 
oO 
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Resource Contention i 


Even though the bus priority feoluton Genwarks de- 
scribed above provide against two or more bus masters 
taking control of the bus at the same time, they do not 
prevent one processor from examining and modifying 
data at the same time that another is operating on this 
data (this is true because data is only transferred in 8 or 
16-bit blocks and the bus may be used by another master 
between transfers). Some technique for inhibiting the 
contention of resources must be provided if true multi- 
processing is to be performed. Three candidates can be 
considered to support this exclusion process. The tech- 
niques required to support each are explored in subse- 
quent paragraphs. ! 


BUS LOCK 


Single board danas provide the capability of lock- 
ing the system bus from access by other bus masters. 
This feature is provided by means of a bus lockout flip- 


- flop which may be set or reset by writing to a dedicated 


I/O port on each board. This flip-flop has the effect of 
keeping the BUSY/ active which keeps the master in 
control of the bus. In this way, a master assures that it 
has exclusive control of a bus common resource. In fact, 
it has exclusive control of all bus resources even though 


LOWER PRIORITY 
- iSBC™ BOARD 


INCREASING PRIORITY 


 —OunNoanunon 
OO Oo OO OO O 


Figure 5. Parallel Priority Implementation 
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it may be using but one of them. This drawback prohib- 
its other masters from using devices on the bus which 
are not in contention as well as those that are. In many 
systems, this potential delay can prohibit the use of bus 
locks in all but a few special applications. 


SEMAPHORES 


Mutual exclusion can easily be obtained by using the 
concept of a semaphore. A semaphore may be thought 
of as a type of traffic signal which can be used to pro- 
hibit access to certain roads or resources. When such a 
semaphore technique is used with microprocessors, it is 
referred to as a test-and-set operation. This means that 
the act of testing the semaphore not only returns the 
current status but also forces the semaphore to the 
‘“‘on’’ condition. If the returned status from the test in- 
dicated a previously cleared condition of the sema- 
phore, the resource associated with it is considered 
available for exclusive use. Since the semaphore is now 
set, all other masters testing it will find a busy condition 
and must wait until the user processor clears the sema- 
phore assocaited with the resource. Each time a proc- 
essor completes its operations on a shared resource, it 
clears the semaphore by writing a zero to it. 


In practice, two types of semaphores are commonly 
found, the hardware semaphore and the software sema- 
phore. The use of each is identical and follows the gen- 
eral concepts outlined in the preceding paragraphs. 


Hardware Semaphores 


Hardware semaphores are those which are implemented 
using physical hardware. Logic components are used in 
circuits which must be designed and constructed by the 


user. Currently, no Intel boards provide for this type of. 
semaphore implementation. Hardware semaphores 
have the advantage over a software implementation of 
being faster and requiring less system: bus time. The 
most common designs consider the semaphore as an I/O 
port although memory mapped designs are certainly 
feasible. __ 


Hardware semaphores are conceptually thought of as a 
D-type flip-flop. A simplified diagram of a typical sem- 
aphore is seen in Figure 6(a). Examining the timing rela- 
tionships of Figure 6(b), it is seen that, if an initial state 
of a clear semaphore is assumed, when a master proces- 
sor reads the I/O port, a data value of ‘‘zero’’ will be 
returned. The hardware immediately sets the flip-flop to 
a logical ‘‘one’’ on the trailing edge of the read signal. 
Any subsequent reads will find the semaphore ‘‘set’’. 
When the user is finished with the resource, it can clear 
the flip-flop by performing a ‘‘write’’ operation to the 
I/O port. | 7 


lOWC! oo: | a | : 


Figure 6(b). Hardware Semaphore Timing _ | 
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The user can prevent.contention of a system resource by 
incorporating a ‘‘wait for semaphore clear’ 


could be used to protect the resource:. ..... 


/* WAIT FOR SEMAPHORE TO CLEAR, LOCK IT */ 
DO WHILE INPUT (035H) < > 0;END; 
/* PERFORM OPERATIONS ON RESOURCE */_ 


i? CLEAR SEMAPHORE TO ENABLE RESOURCE “/ | 


OUTPUT (035H) = 0; 


The: hardware seilaphois is. seen. to be. an. effective 
method of incorporating mutual exclusion in a multi- 


processing application. Its major asset is that it mini- 


mizes system bus overhead and assures maximum bus 
throughput by higher priority master devices. Its weak- 
ness is the requirement for the user to provide hardware 
to implement the semaphores. In many cases, the ous 
overhead incurred by continuous sampling of the sema- 
phore when it is busy can be eliminated by providing a 
system bus interrupt each time a semaphore is cleared. 
If this technique is used, a processor desiring a busy 
resource could enable the appropriate interrupt level, 
then wait until the semaphore is cleared by the current 
user. 


Software Semaphores 


The concept of software semaphores has long been used 
in programming applications. A byte of memory is re- 


served for the semaphore or flag and this byte is then; 


tested by software programs to convey data. This imple- 
mentation is not valid for multiprocessor designs since 
there is nothing to prevent a second processor from test- 
ing and finding a semaphore clear while the first is 
attempting to set it. To be effective in multiprocessor 
systems, the software semaphore must exhibit the char- 
acteristics of the * ‘test-and-set”’ 
tation. 


Many Intel single board computers such as the iSBC 
86/12A board incorporate a special instruction prefix 
which provides the test-and-set feature. This prefix, the 
LOCK, causes the processor board to maintain control 
of the system bus while the byte or word operand is 
tested and set. PL/M-86 incorporates a special instruc- 
tion which implements the software semaphore. The use 
of this instruction is: | 


oldvalue = LOCK SET (memory address, newvalue) 


This instruction causes the processor board to lock the 
bus and place the new value into the specified memory 
location. The old value is returned to the calling pro- 
gram. Only then will the bus be unlocked. An example 
demonstrates how this provides mutual exclusion of a 
resource. 


Assume that a software semaphore, LOCK$BYTE has — 
been declared. A value of 1 indicates that the resource is 


* into .his. 
program. For example, if a resource is protected by a. 


semaphore at I/O. port 35H, the following PL/M code __ executed, : 


hardware implemen- — 


being used and is not available. A value of 0 indicates 
that the common resource is available to a task. If the 
function reference LOCKSET(@LOCK$BYTE, 1) is 
the value of 1 will be assigned to’ 
LOCK$BYTE. Furthermore, the old value of the sem- 


-aphore will be returned. If a value other than 0 is re- 


turned, the statement must be repeated as the resource is. 
being used by another task. When a value of 0 is re- 
turned as the old value, the resource has been dedicated 
to the calling task. When the task is finished with the 
shared resource, a zero. must be written to the sema- 
phore byte. 


A similar technique can be used with 8-bit single board 
computers. For example, consider the iSBC 80/30 
board. Provision has been made to provide a bus lock 
condition when the CPU SOD (the SOD is a output data 
line unique to the 8085 processor which is normally in- 
tended to be used as a serial output line) is active. A task 
desiring to gain exclusive access to a common resource, 
can lock the bus, then test and set the semaphore flag; 
finally, the bus can be freed by clearing the SOD signal. 
An example will make this more clear. | 


Consider the same semaphore which was used in the 
PL/M-86 discussion. A task executing on an iSBC 
80/30 board and desiring to use the protected resource, 
would have code similar to the following: 


/* WAIT FOR RESOURCE AVAILABLE */ 

OLDVALUE = 1; 

DO WHILE OLDVALUE = 1; 
CALL S$MASK (0COH); /* lock bus “7 
OLD VALUE = LOCK$BYTE; /* get old value */. 
LOCK$BYTE = 1; _/* set semaphore ¥/ 
CALL S$MASK (040H); “ff * unlock bus */ 

END; 


/* Perform necessary operations on protected resource */ 


/* Unlock resource for other tasks to use */ 
LOCKS$BYTE = 0; /* clear semaphore */ 


Other boards use a dedicated I/O port to control the bus 


lock feature. For example, the iSBC 80/24 single board __ 


computer has dedicated port D5 to control the lock. | 
Writing a 1 to this port will lock the bus and writing a 0. 
will unlock it. With this exception, the technique shown 
for the iSBC 80/30 board will work when using the 


_ ISBC 80/24 DICeessOl board ina muliprocessie appli- ° 


cation. 


Ill. MULTIPROCESSOR COMMUNICA:- 
TIONS 


For efficient operation of a system solution which uses 
more than one processor, a means must be found to. 
transmit data between the system bus master boards. 


The data, so transferred, might be used to pass param- 
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eters, to move data strings, or to synchronize events on 
the various boards. While it is not the intent of this 
application note to fully explain all possible techniques, 
it does provide some insight into the most common 
multiprocessor data transfer methods. 


After a short discussion of various transfer mecha- 
nisms, the techniques used in the RMX/80 nucleus are 
described. The descriptions provide a basis for the 
development of an extension to the nucleus which 
allows tasks to reside on multiple boards in a multi- 
master environment. 


The most straightforward technique to communicate 
between processors is the use of flags or semaphores to 
synchronize operations. The procedures used in this 
type of data transfer have been explained in previous 
paragraphs. As will be seen, this technique will be later 
combined with more complex methods to synchronize 
the transfer of data. 


A second type of communications which may be used 
involves creating and maintaining data queues. This 
method was created to support a special case of multi- 
processing, the use of intelligent slaves. The creation 
and support of data queues has been thoroughly de- 
tailed in an Intel application note, AP-53, Using the 
iSBC 544 Intelligent Communications Controller. It 
should be noted that, even though created for intelligent 
slaves, the technique is certainly applicable to the gen- 
eral case of multiprocessor communications. 


The generalized data queue is designed to primarily deal 
with the movement of data strings between processors. 
The queue provides independent operation for each of 
the two involved processors, which may operate upon 
the data contained within the queue independently. The 
queue handlers, however, must interact since the queue 
pointers must never be allowed to pass each other or in- 
valid data would be handled. This implies that mutual 
exclusion must be applied to the pointers to quarantee 
their integrity. If this is done, the queue can readily be 
applied to the special cases where string data transfers 
must take place between various processor boards.’ 


Multiprocessor systems infer that the application breaks 
down into functionally independent blocks or ‘‘tasks’’. 
Frequently, these global tasks will most often be further 
subdivided into smaller on-board or local tasks. These 
systems will frequently use real-time executive operating 
systems. s | 


Communications between tasks can involve the trans- 
fer of many types of information. In some cases, data 
strings must be moved. In others, the transfer may be 
only used for synchronization of events. Intel’s 
RMX/80 multitasking operating system supports the 
movement of data (messages) through the use of ex- 
changes. In this implementation, actual messages are 
not moved in memory, but instead, a pointer is gener- 
ated to the message area and this variable is passed 
between tasks. Before proceeding with the development 
of a multiprocessor message driver, some time must be 


taken to assure that the message/exchange relationships 
are fully understood by the reader. 


Messages 


A message is a collection of data that one task sends to 
another task. It may be thought of. in the context of a 
letter which is to be sent from one person (task) to 
another. Like a letter, the purpose of the message is to 
convey information or to request a service. Messages 
used in RMX/80 systems conform to a standard format 
similar to conventional letter connotations. It contains a 
heading and a variable length data area. The heading 
can be from 5 to 9 bytes in length and corresponds to the 
format shown in Figure 7. 


The LINK PORTION of the heading is used by the 
RMX/80 nucleus to keep track of other messages which 
are addressed to the same place (exchanges). If no other 
messages are present, the field will be set to zero. 


Seee (D ~“ oa ff PPD oOo 


Figure 7. RMX/80™ Message Format 


Exchanges 


The exchange can be thought of as a mailbox into which 
messages are placed. In reality, only the location pointer 
of the message is placed into the exchange. Each ex- 
change is defined by an Exchange Descriptor area of 
RAM memory. The format of an Exchange Descriptor 
is shown in Figure 8. The purposes of each field will be 
defined in the following paragraphs and should be 
understood since the development of a multiprocessor 
RMX/80 exchange protocol will use many of these 
fields. 


| MESSAGE TAIL 


TASK HEAD 
TASK TAIL 
EXCHANGE LINK 


Figure 8. RMX/80™ Exchange Descriptor 


MESSAGE HEAD is used to provide a pointer to the 
first message which has been placed into the exchange. 
If no messages are present at an exchange, the value of 
the field will be set to zero. As will be seen, this field can 
be tested by a task to determine if a message is already 
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waiting at:an. SSHEHES anor the sg is. to: ) accept & a 
message. Te | 


MESSAGE TAIL srovides a pointer to the last message 
waiting at an exchange. If no messages are waiting, the 
“pointer will be set to the address’of the exchange. The 


multiprocessor interface which will ‘be designed must - 


provide an update capability for maintaining this field. 


TASK HEAD i isa pointer to the first task which i is wait- 
ing at the exchange for a message. If no. task i 1S waiting, 
this field will be set to Zero. Again, a simple test, when 
‘sending | a message to see ifa task i is to be activated, 1s to 
test the field for a zero value. 


TASK TAIL provides another pointer which adie 
the last task which is waiting at an exchange. As with the 
Message Tail, the field is set to the address of the ex- 
change when | no ‘task is waiting at the exchange. 


EXCHANGE LINK contains the address of. the next 
Exchange Descriptor in the list of all the exchange 
descriptors in the system. This value is established by 
the RMX/80 nucleus and does not require special atten- 
tion in the multiprocessor modifications. 


RMX/80™ Nucleus Communications 


This section of the application note will deal with the 
‘generation of an RMX/80 extension which will allow 
_the transfer of messages between tasks which reside on 
different processors. Three RMX/80 operations will be 
supported and parallel procedures developed. These will 
be the nucleus functions RQWAIT, RQSEND, and 
RQACPT. 


RQWAIT is used to allow a task to receive a message 
from.an exchange. If a message is available, its location 
will be transferred to the receiving task and program 
execution will continue. When no message is available, 
the task will be placed on the wait list until such time 
that a message has been placed into the exchange by 
some other task. RQWAIT provides for the capability 
of allowing a maximum time during which a task will 
wait at .an exchange for a message. The multiprocessor 
equivalent of this function which is.:explained in this 
application note is identified as IPWAIT. It is func- 
tionally. equivalent except. that no provision has been 
made to support a maximum time interval. 


RQSEND is a procedure which allows a task-to send a 
message to an exchange. If no tasks are waiting at the 
exchange, the message will be queued with any other 
messages which may already be waiting there. If a task 


is found to be waiting at the exchange, it will be placed 


onto the ready list so that it can compete again for proc- 
essor resources. The multiprocessor equivalent. defined 
by this note is called IPSEND. 


RQACPT provides a procedure which gives a task the 
ability to test an exchange to see if a message is present. 
If one is waiting, its address will be returned to the call- 
ing task. a no message is available, a value of zero is 


returned. The: AE DrOeessot equivalent, is ae 


IPACPT. 


The concepts used to develop each of the three exten- 
sions are ‘discussed in the following paragraphs. Not 


only should this development assist the user in creating a 


multiprocessor executive, but it should also help in the 
understanduig of the operation of the RMX/80 BUeeee 


Multiprocessor Message Transfers 


Normal message transfers take place between tasks 
which are resident on the same processor board and thus 
are able to share a common memory area for the storage 
of the message’s data. When a multiprocessor configur- 
ation is implemented, these tasks may not necessarily 
have all: memory.areas accessible to each other. An area 
of: memory which is common.to all processor boards 
must be created to implement a multiprocessor system. 
This memory will be hereafter referenced as GLOBAL 
memory. All common resources which may be needed 
or used by a task which might have a need to perform 
multiprocessor operations must use the Global memory 
area. 


The lente aibi ofa RMX/ 80 extension which pro- 
vides a multiprocessor communications driver can be 
performed using the knowledge gained from the defini- 
tions of the fields in the messages and exchanges. The 
development will begin with the eoneents involved in 
executing an exchange wait. 


WAITING FOR A MESSAGE 

First consider the condition in which a message is wait- 
ing at the specified exchange when the task performs a 
request to obtain a message from an exchange. In this 
case, the message can be accepted directly (and the 
pointer fields updated accordingly) and the task can 
proceed normally. The sequence of events for this type 
of condition can be seen in the flow chart of Figure 9. A 
complete listing of the code can be found in Appendix 
A. References will be made to lines of code which are 
pertinent to the discussion by using a pointer in paren- 
thesis. Thus a reference to code at line (1.14) will indi- 
cate program 1, line 14 in the appendix. 


The procedure can examine the LINK field of the mes- 
sage to determine if more than one message is waiting at 
the exchange (1.36). A ZeTO in the field indicates that no 
other messages are present. The value of the LINK field 
should be moved into the MESSAGE HEAD field of 
the Exchange Descriptor (1.36). The MESSAGE TAIL 
field should reflect the last message. If more messages 
are present, the field can be left unchanged; otherwise, 
the field should be set to the exchange address. The ad- 
dress of the message is returned to the calling program, | 
allowing’ it to use the data contained in the message 
(1.40).. Note how the use of a software semaphore has 
been used to prevent more than one processor modify- 
ing the exchange and message descriptor data at ‘the 
same time a. 24; 1. 1.39). | | ; 
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The technique described above provides a direct ap- 
proach to getting a message from an exchange. A more 
Fe regeTanES. complete methodology is required when a message is not 

waiting at the exchange. This is the subject of the fol- 
lowing paragraphs. 


As tasks queue up at an exchange waiting for a message, 
provision must be made to create and maintain a link 
list of those tasks. Since the source code associated with 
RMX/80 is not normally available to the user, the effect 
of using the existing data structures cannot always be 
determined. An extension must be developed which will 

ae support the maintenance of a link list of queued tasks. 

ONE Thus, each task descriptor will have a THREAD pointer 
MESSAGE added which will point to the next task waiting at the ex- 
change. Each exchange descriptor will have two fields 
added, one for use as a TASK HEAD pointing to the 
ROnGREXCHINCE first task waiting at the exchange, and a second field, 

MESSAGE TAIL TASK TAIL which points to the last task waiting at the 
exchange. These fields will be added to the existing 
RMX/80 descriptors for those tasks and descriptors 


ADJUST EXCHANGE which are associated with multiprocessor operations. 
MESSAGE HEAD 


4 


SEE TEXT 


Figure 10 provides representations of the exchange and 
task descriptors as they would be configured for various 

SET MESSAGE LINK i ; ae 
TO MESSAGE ADDRESS conditions. Consider first the condition in which one 
task is already waiting at an exchange. The TASK TAIL 
and the TASK HEAD will be pointing to the task de- 
UNLOCK DATA scriptor of the waiting task. Since only one task is wait- 
la ide ing, the THREAD field of the task will contain a zero 
value. Appendix A contains the listing of the code re- 
RETURN MESSAGE quired to add a task to the exchange queue. The pro- 
ADDRESS gram is the same as the one previously discussed when a 
message was waiting at the exchange as the calling task 
attempted to obtain a message. If the test indicates that 


Figure 9. Getting a Message from an Exchange no message is present (1.25), the fields must be updated 


TASK 
EXCHANGE DESCRIPTOR 
DESCRIPTOR 


1 
| 2 ONE TASK WAITING 


IPSTASKSHEAD IPSTHREAD 


IPSTASKSTAIL (VALUE = 0) 


TASK TASK 
EXCHANGE DESCRIPTOR DESCRIPTOR 
DESCRIPTOR 2 


1 


IPSTASKS$HEAD IPSTHREAD IPSTHREAD 


IPSTASKSTAIL (VALUE = 0) 


EXCHANGE 
DESCRIPTOR 


: NO TASKS WAITING 
IPSTASKSHEAD =0 | 
IPSTASKSTAIL 


Figure 10. Task Queuing at an Exchange 
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as shown in Figure 8 and add the new task to the waiting 
list. The RMX/80 nucleus maintains the address of the 
task descriptor of the task currently running in a vari- 
able, RQACTV.. This pointer to the current task must 
be placed into both the TASK TAIL of the exchange de- 
scriptor and into the THREAD of the last task queued 
onto the exchange (1.29). In addition, the THREAD of 
the current’ task should be set to zero to indicate that it 
will be the last task waiting at the exchange (1.30). — 


The reader, studying the program listings, might note 
the condition of the exchange having no tasks waiting 
when the task is queued up (1.28; 1.29). In this case, the 
TASK TAIL pointer is clearly pointing to the exchange 
descriptor and not to a task! The pointer normally 
placed into the task descriptor’s THREAD field will be 
placed into a field. of the exchange descriptor. This 
potential trouble area is overcome by constructing the 
fields of both descriptors to have offsets equivalent as 
shown in Figure 10. The THREAD data will now be 
placed into the TASK HEAD field as should be done if 
no tasks are already queued up. 


Finally, since the task should no longer compete for 
system resources until a message is available to it, the 
program should be placed onto the delay list: However, 
since this list is maintained by RMX. primative proce- 
dures which are unavailable to the user, the same effect 
can be obtained by constructing a multiprocessor user 
wait list and then suspending the task (1.32). At this 
point, the nucleus will activate another task from the 
ready list and the suspended task will remain in that 
state until it is resumed. When resumed, program execu- 
tion will begin at (1.35), where a pointer from the 
DELAY pointer of the task descriptor will be returned 
to the calling program. Programs which will activate the 
task must ascertain that the pointer contains a reference 
to the message which is to be received by the task. © 


SENDING A MESSAGE 


The conditions which may be encountered in perform- 
ing a sending of a message to an exchange must now be 
considered. Two paths must be explored in the discus- 
sion; the operations required when a task is waiting at 
the exchange and the operations used when a task is not 
already waiting. The program which is constructed to 
support the required operation is called IPSEND and 
will have its line numbers referenced as (2.n) where n is 
the line number on the listing. 


If the exchange to which a message is being sent does 
not have a task waiting (2.26), it is only necessary to 
modify the descriptors to indicate the presence of the 
message. Figure 11 shows the field pointer requirements 
for the various conditions which may be encountered at 
the exchange when no task is waiting. 


An exchange having no messages already present will 
have the MESSAGE TAIL pointing to the exchange 
descriptor. A message structure of the last message at 
the exchange will be defined based upon the MESSAGE 


TAIL and the first element of the structure will be set to 
point to the new message (2.28;.2.29). When no message 
was already queued, this action will set the MESSAGE 
HEAD to the new message. When a message was pres- 
ent, the LINK field will be set to point to the new mes- 
sages. Next. The LINK field of the new message will be 
set to zero, indicating that it is the last message in the 
queue (2.30). Operation of the program can then con- 
tinue. 


EXCHANGE 
DESCRIPTOR 


MESSAGE TAIL 


EXCHANGE 
DESCRIPTOR 


MESSAGE 


MESSAGE TAIL 


EXCHANGE 
DESCRIPTOR 


MESSAGE TAIL 


MESSAGE MESSAGE 


Figure 11. Placing a Message in an Exchange 


The operations become more complex when one or 
more tasks are already waiting at an exchange for a mes- 
sage. In this case, the task will have been suspended as. 
was shown in the previous discussion about waiting for 
a message. A technique must be established to again 


-cause the waiting task to be placed on the ready list of 
the RMX/80 nucleus. | 


Conceptually, this can be done by generating an inter- 
rupt which will cause all processors to test if they are the 
one which controls the task which is waiting at the ex- 
change to which the message has been sent. If not, no 
action will be taken by that board. If the task resides on 
the single board computer responding to the interrupt, 
the suspended task can be resumed and placed again on 
the ready list. For the purposes of this application note, 
interrupt level 4 will be used to provide the mechanism 
to cause each system processor to determine if the task 
to which the message is directed resides on that board. 


The generation of an interrupt onto the Multibus system 
bus is implemented on newer iSBC boards by merely 
adding jumpers to wire wrap posts on the board. Figure 
12 shows the schematic of the interrupt mechanism 
associated with interrupt level 4 on the iSBC 80/30 
single board computer. An interrupt can be generated 


-onto. the Multibus system by toggling bit 7 of the I/O 
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port. Note that the interrupt is also routed back to the 
source board, so all processor boards, including the one 
generating the interrupt, will respond to it. 


INTR4/ 


CONTROL PORT = EB 


Figure 12. Interrupt Mechanism 


A program has been written and is shown in Appendix 
A which generates the required interrupt onto the 
system bus. The program is identified by the name 
SETSINT and is referenced in this application note with 
the pointer scheme (3.n) where n is the line number of 
the code. | 


Of specific interest in the program listing is the use of 
software semaphores to provide an indication of the 
length of time which the interrupt line must be kept 
active. Semaphore 6 is used to provide mutual exclusion 
to the interrupt gneration mechanism (3.11) and sema- 
phore 5 provides the synchronization mechanism. The 


EXCHANGE 
DESCRIPTOR 


TASK #1 
DESCRIPTOR 


latter semaphore is set prior to establishing: an active 
condition on the interrupt line (3.13). When the pro- 
cessor having the task which is to be activated recog- 
nizes the interrupt, it will clear the semaphore level. The 
interrupt should be held active (low) by the processor 
board which generates the interrupt until the semaphore 
has been cleared (3.16; 3.17). | 


Note that in line (3.14), a processor identification num- 
ber was stored in the variable PROCS$ID. The technique 
which can be used to obtain this target processor refer- 
ence is to store the processor number into the exchange 
descriptor STATUS field when the task is queued onto 
the exchange descriptor (1.27). When the message is 
finally sent to the exchange and the task is taken off the 
exchange descriptor (2.40), the identification can be 
stored for use by the interrupted processor. Any proces- 
sor which receives an interrupt with an identification in 
PROCS$ID which does not match its own processor 
identification should ignore the interrupt. 


Figure 13 shows the process of dequeueing a task from 
the exchange descriptor. Since one or more tasks were 
waiting at the exchange, no messages could exist at the 
exchange. The first operation (2.36) involves adjusting 
the pointer to the first task waiting at the exchange to 
point to the next waiting task (if only one task was 
waiting, the value of zero will be stored as a pointer). If 
only one task is waiting (2.36), the exchange task tail is 
set to point to the exchange (2.37). The message link and 
the task delay pointers must be set to the address of the 


MULTIPROCESSOR 
VARIABLES 
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STATUS (PROC ID) 


IPSTHREAD 


WAITING FOR A MESSAGE 


IPSTASK$HEAD 
IPSTASKS$TAIL 


INT$PROCSEXCH = 0 
=r eee 


PROCSID = OFFH 
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Figure 13. Dequeueing a Task 
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message (2:38) to'‘support standard RMX/80 protocol. 


The.task delay pointer is used by the receiving task to 


pass. the address of the message when it returns to the | 


active condition (1. 33). 


Before. generating the interrupt which will place the 
waiting task onto the ready list, parameters which iden- - 


tify the task’s processor (2.38) and internal descriptors 
(2.39) must be placed into a-global memory area. As will 


be seen, this area can then be tested. by each processor 


when an interrupt is received. An interrupt can now be 
generated which will cause all processors to examine the 
multiprocessor global memory to determine if the mes- 


sage is directed to a task which resides on that processor 


board. 


RESPONDING TO INTERRUPT REQUEST 


As the interrupt is generated, each processor in the Sys- 
tem will service the request. An RMX/80 task can be 
written which waits at the interrupt exchange and which 
will service the interrupt request. However, in order to 
optimize the system performance, a user interrupt 
routine has been provided. A listing of this program, 
INT4, can be found in Appendix A. Code line numbers 


for this listing are identified by the nomenclature (5.n) 


where n is the line number of the code. | 


The program will first test the target processor identifi- 
cation (5.40) to determine if the task to be placed onto 
the ready list resides on the board. If the interrupt is 
found to be for another master, it will be ignored and 
the interrupted program will continue (5.41). _ 


If, however, the processor is the recipient of the mes- 
sage, the global field containing the identification is 
cleared (5.43), the interrupt is acknowledged (5.44) 
allowing the sending master to continue the execution of 


its tasks, and a message is sent to the RMX/80 interrupt 


handler task, INTHND (5.45). 
The interrupt handler continues with the INTHND pro- 


cedure which is identified by the use of (6.n) where nis | 
the line number of the code in the procedure. This task _ 


operates under the standard RMX/80 nucleus and is 
waiting at an interrupt exchange (6.34) for an interrupt 
message to be sent by the interrupt handler program, 
INT4. A second validity test is then performed (6.36) to 
verify that a multiprocessor message has actually actu- 
ated the task and that the interrupt is not to a spurious 
noise signal. The task pointer is saved and then cleared 
- to allow transfer of additional messages. (6.38; 6.39). 


The task which was waiting at the exchange is then again 


placed onto the ready list by performing a ‘‘resume’’ 


RMX/80 command (6.42). Thus, the-transfer of a mes- 
sage between two tasks residing on either. different or — 


the same processors has been completed. 


TESTING AN EXCHANGE 


Many times it is required to test an exchange for the — 


presence of a message without actually waiting if no 


message is available at the time. This is the function of 
the standard RMX/80 procedure RQACPT. A multi- 
processing version of: this function, IPACPT, was in- 
cluded in.the extension to. the RMX/80 nucleus. It is 
found in Appendix A and is identified by the references 
(4.n). | 


Basically, the program need only determine if a message 
is present at the exchange. This is done by testing the ex- 
change message head field (4.25) for a non-zero value. 
If no message is present, the value will be set to zero and 
a return to the calling task can be performed which indi- 
cates that no message was found (4.28). If a message is: 
found, the functions defined in IPWAIT can be exe- 
cuted to adjust the descriptor fields and return the mes- 
sage address. This is most easily accomplished by simply 
calling the IPWAIT procedure (4.32). 


INITIALIZATION OF DESCRIPTORS 


Before the multiprocessor message exchange procedures 
just described can function properly, various data fields 
must be initialized just as is done by the RMX/80 
nucleus. Two programs have been written to accomplish 
this task. One, the GLINIT program, initializes the 
common global variable fields which are common to all 
processors.: This includes such fields as the processor 
identification (7.14) and the target task pointer (7.9). 
This program also initializes the extensions which have 
been made to the exchange descriptors (7.10). 


A second program operates on functions which are 
unique to each processor board in the system. For exam- 


_ ple, the I/O ports used to generate the global interrupts 


must be initialized to the correct state (9.43). The inter- 
rupt exchange (9.45) and interrupt handler (9.46) must 
be created and linked to the nucleus. Since user written. 
interrupt service routines are used, they must also be 
defined to properly vector the interrupts when they oc- 
cur. This is the function of lines (9.47) and (9.48). 


If a board other than the iSBC 80/30 computer were 


_ used in the system, this second initialization routine 


would require modification to adjust it to the peculiar 
characteristics of the board used. 


_ USE OF SEMAPHORES 


All of the tasks which provide a multiprocessor mes- 


_ sage transfers rely upon the ability of procedures to 


exclude access to the RMX/80 extension which provides. 
this capability until. the message has been transferred or 


queued onto an exchange. This is done using sema- 


phores in two programs identified as LOCK and 
UNLOCK. The same techniques which were earlier 


- described are used and can be seen in the Appendix list- 


ings. Since the processors used in this application note 
were ISBC 80/30 single board computers, a bus lock 


command (8.17) for that board was used. The use of 


other boards, would require a modification of this in- 


_struction to conform to the board design. The bus lock 
command has no effect on memory which is accessed 
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using the on-board local bus. In order to provide an 
effective semaphore, the RAM used for a software 
semaphore must reside in a memory area which is exter- 
nal to the processor board. For this reason, the dual 
ported memory of an iSBC 80/30 board cannot be used 
and memory which is not contained on a board which 
uses the semaphore must be included in the system. 


System Resource Sharing 


Many of the advantages of a multiprocessor system can 
be lost when drivers and peripheral devices are dupli- 
cated for each single board computer. For example, 
consider a system which maintains an on-going inven- 
tory system on a mass storage device such as a disk 
drive. If distributed single board computers are used to 
support each individual operation of a product as it 
moves through the process, only a common disk system 
will allow modification of the data base by each proces- 
sor. If a means can be found to also share the driver to 
the disk, considerable programming effort and code 
space can be saved. 


The RMX/80 nucleus is designed to support many spe- 
cial I/O device handlers such as the terminal handler, 
and the disk file system (DFS). An intermediate level in- 
terface can be constructed which will allow any of the 
system processors to use common drivers on one master 
board. The program which will be developed in this ap- 
plication note for interfacing with common system 
drivers is called BIPI. A listing of this program can be 
found in Appendix B. 


Several options exist when selecting a target device 
which is to contain all the required system resources. 
One possibility is to arbitrarily pick a processor board 
and configure the necessary drivers onto it. However, 
another choice seems to present many more system ben- 
efits. This is the dedication of one processor board to 
the operator interface and then using the iSBC 802 
RMX/80 BASIC interpreter on this board. Consider, 
for a minute, the implications of configuring a system in 
this manner. 


‘It is a fact that minimal development cost will be in- 
curred if the programming is done in a high level 
language. Unfortunately, systems involving large 
amounts of digital input and output, or having to inter- 
face with peripheral controllers, do not lend themselves 
well for programming with a high level language. On the 


other hand, it is difficult to perform data manipulations © 


of strings and numerical data using programs written in 
lower level languages. An optimum solution is then to 
create a system which combines the attributes of both of 
the language types. 


An analogy can be drawn between a conventional single 
processor system and one which uses multiprocessors. 
In the system which uses a single processor, assembly 
language routines can be written for minimum code size 
or time critical functions and can be linked with PL/M 
or FORTRAN programs to produce the final object 


module. A multiprocessor system can be thought of in 
the same manner. Here, individual functions are repre- 
sented by a complete single board computer, each of 
which can use some combination of the available lan- 
guages. System design can emphasize the positive attri- 
butes of each language which is available. 


The iSBC 802 BASIC package can be included in a 
multiprocessor system much the same as a common sub- 
routine in smaller systems. Various other processor 
boards can use the I/O capabilities of the BASIC inter- 
preter as needed. In particular, the DFS (Disk File Sys- 
tem) and terminal handler can be shared as needed by 
each board. 


Because the I/O drivers contained in the BASIC Inter- 
preter use standard RMX/80 exchanges, they cannot be 
directly accessed using the multiprocessor interface 
which has been developed earlier in this application 
note. A special intermediate interface is required which 
will interface with the iSBC 802 software. This is the 
function of the program, BIPI, which will be linked 
together with the other tasks contained on the single 
board computer used for the BASIC interpreter. Cer- 
tainly, the concepts which will be used to develop the in- 
terface to the common I/O services of the iSBC 802 
software can easily be extended to support other pack- 
ages such as the iSBC 801 FORTRAN run-time pack- 
age. 


Requests to have a service performed by the BIPI 
module will be received in the form of a message to the 
global exchange, BIPISEX. A definition of services 
which may be required by a remote processor will pro- 
vide the basis for a definition of message types which 
will be supported by the interface. 


A fundamental request will be to gain access to the 
operator keyboard or display terminal. Thus two 
message types can be defined to read from the terminal 
keyboard (READS$TYPE) and to output to the display 
(WRITESTYPE). To provide process tasks with the 
ability to examine and modify data which is stored on 
the disk drive media, a set of commands must also be 
generated which interface to DFS. Five command types 
will prove to be sufficient for this task. Corresponding - 
to the RMX DFS disk message types, the program will 
define disk open operations (DFS$OPN) and close 
operations (DFS$CLS). Positioning capabilities are sup- 
ported by a seek command (DFS$SK). Finally, read and 
write requests are supported by the read & DFS$RD) and 
write (DFS$WT) commands. 


Examination of the program listing will indicate that 
disk request message types use the type numbers from 
72 to 79. This provides a simple method of distinguish- 
ing a disk request from a terminal operation message. 
The numbers were chosen such that subtraction of 64 
from the message type will yield the message type which 
must actually be sent to the DFS exchanges by BIPI. 


In many cases, it may be desirable to suspend the 
BASIC program (or the FORTRAN program) while 
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peripheral I/O resources are being shared by another 
processor. An example might be when a task is report- 
ing an-alarm condition to the operator .and requires 
some interactive communications with him. Certainly, 
these communications cannot be intermixed with mes- 
sages from the program which was running on the ter- 
minal. Therefore, two additional commands have been 
provided which will suspend (SUSBAS) and resume 
(RESBAS) the task which might have been competing 
for a system resource. 


Study of the program hs for BIPI will provide the 
reader with an insight into the use of the multiproces- 
sing RMX/80 extensions which have been developed in 
this application note. Both standard RQ... calls and 
multiprocessor IP . . . calls are integrated into the task. 
When the concepts are clear, a real application example 
can be examined to see how multiprocessing can assist in 
the solution of an otherwise very complex design prob- 
lem. 


IV. APPLICATION EXAMPLE 


The previous development of multiprocessing exten- 
sions to the RMX/80 nucleus allows the application ex- 
ample development to continue. A solution using multi- 
processor. techniques can be easily implemented using 
these concepts and the extensive line of Intel single 
board computer products. The results can be examined 
to verify that multiprocessing has provided a better 
solution than would have been gained if only one proc- 
essor had been used. 


The merits and deficiencies of multiprocessing must. be 
examined to ascertain that the application is likely to 
benefit from a solution which uses more than one proc- 
essor. Certainly, many functions can be better per- 
formed using a higher speed ae igen! on a Single 


iSBC 204™ 
DISKETTE 
CONTROLLER 


~ iSBC 032™ 
MEMORY 
EXPANSION 


board. The. decision :to use multiprocessing must be 
made on a cost/performance basis. 


The application defined at the beginning of this applica- 
tion note provides an excellent example of the multi- 
master ‘solution. Each functional séction of the applica- 
tion is developed into an actual board implementation 
which includes all resources required for its support: 


Supervisor Implementation - 


The supervisory functions are likely to require extensive 
computational functions; report. generation and oper- 
ator interaction. It is also likely that, as the management 
gains experience with the system, the functions required 
and the algorithms used will be constantly modified. 
These operations are not generally real-time. driven so 
extremely high system throughputs will not be required. 
The Intel iSBC 802 BASIC package running on a single 
board computer will provide a solution to these require- 
ments. In terms of. hardware design, the supervisory 
functions can be considered without regard to any con- 
trol functions. The primary interface can be. through 
data bases stored on a mass storage device and with the 

‘“neek’”’ and ‘‘poke’’ instructions where necessary. The 
system configuration for the supervisory function can 
be seen in Figure 14. 


Because the supervisor will rely extensively upon the 
interaction with the operator and the mass storage 
devices, it is natural that it have associated with it the 
terminal handler and the DFS system. The addition of 
the BIPI interface task to the BASIC interpreter pack- 
age will allow the control tasks to easily interface to the 
inventory and control data bases as required. Figure 15 
shows the primary tasks which operate on the supervisor 
control processor. Note that there exists two operating 
tasks, BASIC and BIPI, along with support functions 
of the DFS and terminal handler. Any program which is 
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‘Figure 14. Supervisory Configuration nes 
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being run under BASIC will essentially become an ex- 
tension of the existing interpreter task. 


Programs can be written which will provide the required 
algorithms to implement the inventory control system 
and production scheduling of the system using a high 
level language which may easily be modified as required 
by the future system requirements. 


The rest of the system consists of control elements. They 
may easily be thought of as supervisor subroutines 
which are called as required and which have parameters 
passed with the call. Unlike conventional designs, these 
subroutines will reside on different processor boards. 


TERMINAL 
HANDLER 


Weighing Ingredients 


One functional task has been defined as weighing the in- 
gredients according to a formula in order to provide the 
correct ratio of ingredients to produce the final product. 
As with most functional areas, a closer examination 
shows that this involves rather complex relationships 
and breaks down into many smaller tasks. Figure 16 
shows the logical flow of operations which are required 
to weigh the ingredients into their proper ratios. From 
the information contained in this flow diagram, tasks 
and exchanges necessary to implement the function can 
be defined and the coding generated. 
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Figure 15. Supervisor Software Structure 
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The tasks which were defined. for this application exam- 
ple are shown in Figure 17. The task communication 
paths through exchanges has also been illustrated in the 
figure. Basically, the weighing function consists of four 
on-board tasks and calls upon tasks contained on other 
boards as. is required using the global exchanges created 
according to the structure defined earlier in this applica- 
tion note. Some time should be taken to explain the 
functions of each task and how they relate with tasks of 


other processors in the multiprocessor design serum | 


The schedule ne ‘SCHDLE, is the interface between 
the operator commands and the weighing functions. 
This task will wait for a POKE command to pass it a 
flag which indicates that a batch is to begin. At this 
point it will organize the data which will be required by 
the weighing task into predefined memory structures 
and will then signal the weighing task to begin its opera- 
tions. A second function performed by the schedule task 
is the initialization of system variables each time a reset 
is performed on the processor board. 


The weighing task, SCALEO, is responsible for actually 
producing the required amounts of each ingredient. All 
the functions indicated in Figure 15 are implemented by 
the weighing task. The task uses resources of other proc- 
essors as well as on-board tasks to assist in the prepara- 
tion of a batch of material. 


A scale driver task, SCLWT, is included on the proces- 
sor as a local support task to assist the weighing opera- 
tions. It is responsible for interfacing with the analog to 
digital converter (ADC) and converting the data re- 


ceived from it into engineering units which represent the 
actual weight of material which is in the scale. The scale 
weights are passed between two tasks using an exchange 
(SCLWTEX) to provide mutual exclusion. 


In wighing applications, many times a feeder will ial: 
function and not deliver material into a scale when 
directed to do so. If no provision is incorporated into a 
system design to detect this condition, an infinite time 
period could be required to weigh a material and, need- 
less to say, the system throughput would be severely 
degraded. A slow fill detection algorithm is normally in- 
corporated into weighing systems to provide this ser- 
vice. For this application, this function is generated 
using a slow fill task, SLOFIL. Functionally, the opera- 
tion of the task is to accept a message from the weighing — 
task that it has commenced weighing a material. 
SLOFIL will then begin a timed wait at an exchange for 
a period which corresponds with the maximum allow- 
able time period for the material to be added into the 
scale. If the time elapses and a message has not been. 


_ received from the weighing task indicating that cutoff 


has been reached, a message will be sent to the weigher 
indicating that a problem with the equipment exists. The 
operator can then be alerted to correct the malfunction. 


The weighing function provides a good example of how 
off-board system tasks can be used to interface with 
those which are on-board to extend the capabilities of 
the system. The sharing of the terminal handler and of — 
the DFS system has already been discussed. The weigh- 
ing function calls upon these tasks, through BIPI, for 
assistance in updating the inventory and when it is 
necessary to communicate with the operator to resolve a 
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Figure 17. Weighing Task/Exchange Relationships 
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system problem. Other examples can also be seen. For 
example, the decision was made to use a common digital 
I/O board for all process functions. This gives the abil- 
ity for access to the control and sensor devices to both 
the controlling tasks and to the operator for performing 
maintenance programs or even operating the system in a 
semi-automatic mode should a controller fail. All I/O 
data is moved through exchanges, PTBnEX, and the ac- 
tual I/O is performed by a task which resides on another 
board. 


Another example of multiprocessor communications in- 
volves message passing between the weighing tasks and 
the mixing tasks contained on another board. The 
weighing task is responsible for discharging the material 
into the mixer, but it certainly cannot do so unless it 
ascertains that the mixer is empty and available. It does 
this by testing the exchange, MIXINT, for the presence 
of a message indicating that the mixer is available. The 
mixer tasks, as will be seen, support this exchange by 
removing the message when no material should be 
added into the mixer and placing a message into the ex- 
change when a mixer is ready. Further communications 
with the mixer are required because the mixer task must 
be synchronized with the discharging of material into it 
by the weighing function. This is provided by message 
transfer through global exchange, MIXEX. 


Finally, because only a limited amount of RAM is avail- 
able in a particular system, the free space manager was 
used in this application to allocate blocks of global 
memory to individual processor boards. This allocation 
is handled by sending messages to the global exchange, 
BUSEX, which will be received by an intermediate task 
on another processor and will result in a block of mem- 
ory being allocated to the weighing task for message 
generation. | 


Other Application Tasks 


A processor was dedicated to support each of the re- 
maining three application processes. It would be repeti- 
tious to again detail each subtask which makes up each 
functional area. The same techniques which were 
demonstrated in defining the weighing application can 
be used to define the generalized functions and to break 
these functions into codable tasks. 


Data is transferred between processors in the form of 


messages which occupy RAM area. The use of the 


RMX/80 Free Space Manager provides a global tool to 
allocate and reclaim this memory area. The Free Space 
Manager was implemented on the mixing processor be- 
cause substantial amounts of ROM remained on-board 
after coding all the required tasks. This ability to select 
from many processors the location for global resources 
is an important tool in multiprocessor applications. 


Total Application Configuration 


Figure 18 shows the functional software implementation 
for the entire chemical application chosen for this appli- 


cation note. The approach has demonstrated that a rela- 
tively complex application can easily and quickly have a 


control solution generated using multiprocessing con- 


cepts. The ability to extend the multitasking capabilities 
of the RMX/80 nucleus led toward the creation of 
modular software. 


APPLICATIONS 


SS APPLICATIONS 


APPLICATIONS 


Figure 18. Software Configuration 


In addition to allowing the generation of modular soft- 
ware, the approach taken on this example has allowed a 
modular approach to the hardware implementation. 
Figure 19 provides the complete hardware block dia- 
gram of the final implemented system. Each functional 
section was designed as though it were the only required 
element to create a solution to the control. problem. 
Indeed, even after start-up, a functional module can be 
removed from the system without affecting the opera- 
tion of remaining modules. The concept can be ex- 
tended to include the capability of adding new processes 
to the total system without having to disrupt the existing 
production flow control. _— | 


V. CONCLUSION | 


This application note has demonstrated how a user can 
extend the concepts of multitasking into a multiproces- 
sing/multitasking environment. The built-in multiproc- 
essing capabilities of the various Intel single board com- 
puters have been explained and ‘their implementations 
demonstrated through examples. ; 


Resource sharing between processors has been dis- 
cussed. In particular, the use of a high level language 
such as BASIC or FORTRAN as a supervisor has been 
explained and shown in an application. Since these soft- 
ware packages contain the resources required for disk: 
support and terminal I/O, a program has been devel- 
oped which will allow other processors to share the 
RMX/80 drivers. | a a 
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Figure 19. Hardware Block Diagram 


Finally; an application has been selected: and a control. 


solution developed using the concepts derived in the ap- 
plication note. The operation of the RMX/80 exten- 
sions have been tested and their operation verified. 


Multimaster operations are possible because of many 


built-in features of the Intel products and the extensions - 
to the RMX/80 nucleus used in this application. A sum-_ 


mary of.these features and the corresponding product 
iS: ; BO a oy | 
Multitasking Capability = 

Furnished by the RMX/ 80 nucleus. It allows the user 


to share the on-board resources of a processor board 
between multiple tasks or functions. 


Message Transfer Capabilities — 


Also furnished by the RMX/80 nucleus. This func- 

— tion allows data to be passed between tasks to pro- 
vide both an information exchange and a means of 
task synchronization. 


Free Space Management’ 


The RMX/80 executive. provides the ability to share. 


memory between various tasks. Memory which is not 
constantly required can be used by more than one 
_ user, then.returned to the memory pool. . » 
Terminal Handler —- 
The RMX/80 terminal handler provides a convenient 


~ resource for supporting the communications s with the 


operator via a CRT terminal. 


Disk File System - — 


The RMX/80 Disk File System (DFS) provides: a 
common resource which allows tasks to access or to 
store data on a diskette. 


Interprocessor Communication Software — 


The software developed in this application note pro- 
vides an extension to the RMX/80 nucleus which 
-allows.tasks to reside on any multimaster board con- 
nected to the Multibus system bus. 


Bus Avsinanon Logic — - 


The Intel single board computers used in hig applica- 
‘tion incorporate bus arbitration logic which. controls 
the bus access to the Multibus system bus. 


Parallel Priority Logic - =a 


The application uses a saraliel priority feeic nenhork 

which is constructed on a prototype board. In con- 

junction with the bus arbitration logic on each multi- 

master board, it controls the requests for data trans- 
fers over se Multibus system bus. 


Bus Lock — ee | 
The capability of assuming exclusive control of the 
Multibus system bus by using the bus lock mecha-. 
nism allows the implementation, of software sema- 
phores. These semaphores are used to provide 
mutual exclusion of certain physical resources. 
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BASIC Interpreter — 


The use of the iSBC 802 BASIC interpreter greatly 
reduces the amount of time required for the genera- 
tion of report programs and of interactive com- 
munications with the operator. 


PL/M 80 High Level Language — 


This softwasre language provides an efficient means 
of coding the application software where intensive bit 
manipulations are required. The structured language 
also provides a rapid development cycle. 


2:151 


The reader should have considerable insight into possi- 
ble system level solutions to applications which he may 
face in his particular expertise. The increased productiv- 
ity which results from applying the engineering/pro- 
gramming resources into application oriented efforts 
can easily be seen. The development costs which can be 
saved by using modular software and high integration 
level board products can certainly justify the use of 
these system solutions. 


I would like to extend my gratitude to Steve Verleye for 
his valuable assistance in generating the multiprocessor 
communications programs used in this application note. 
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1 IPWAIT: 
do; 
/* 


FEFLEEFAF EEE EEF EAE EPTFE EEE EEE EE EE EEE EEEEEEE FEEL AE EEE EE AL EE EEE EEE ETH 
PUBLIC PROCEDURE: IPWAIT. LAST CHANGED 11/07/79 


This procedure provides the inter-processor wait facility. 
If a message is available at the given exchange it is 
taken off the exchange and its address is returned to the 
calling routine. If no message is available, the processor 
ID is encoded in the status field. the task address is queued 
On the exchange list, and the task is suspended. When a 
message is sent to the exchange by another processor, the 
processor ID is used to send the task and message addresses 
into the incoming task queue for the processor and then interrupt 
it. The service routine thus activated sets the delay field of 
the indicated task equal to the message address and RESUMES the 
task. The task then simply RETURNS the stored message address. 

HF AEEEEE EEF ELE EEE EEE FE EEE EEE EEE EEEEEFEA EEA EE HEE EEE PEPE HEHEHE tHe testes 


ay 


Sinclude (:£1:g lobal. ext) 
/* Declaration of global inter-processor data 
structures */ 


MSGSHDR, 
REMAINDER(1) BYTE) '; 


2 1 = declare 
= procSid byte external, 
= taySpid byte external, 
= inSque address external; 
3 1 = declare | 
= mySvrocSid literally ‘mySpid', 
= intSprocSexch literally inSque'; 
Sinclude(:f£1:sema.ext) | 
4 1 = lock: procedure (semaSid) external; 
5 2 = declare semaS$id byte; 
i) 2 = end; 
7 1 = unlock: procedure (semaSid) external; 
2 = declare semaSid byte; | 
y) 2 = end; 
Sinclude (suspnd. ext) 
19 1 = RQOSUSP : 
= PROCEDURE (TSPTR) EATERNAL; 
1l 2 = DECLARE TSPTR ADDRESS; 
12 2 = END. ROSUSP; 
Sinclude (msg.elt) 
13 1 = DECLARE MSGSHOR LITERALLY ' 
= LINK ADDRESS, 
= LENGTH ADDRESS, 
= TYPE BYTE. 
= HOMESEXCHANGE ADDRESS, 
= RESPONSESEXCHANGE ADDRESS'; 
14 jl] = DECLARE MSGSDESCRIPTOR LITERALLY ‘STRUCTURE ( 
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Sie einata: fl: eee: elt) 
DECLARE IPSTASKSDESCRIPTOR LITERALLY. "STRUCT URE ( 
DELAYSLINKSFORWARD ADDRESS, 
DELAYSLINKSBACK ADDRESS, 
THRRAD ADDRESS .- 
DELAY ADDRESS, | - 
EXCHANGRS ADDRESS ADDRESS, 
SP ADDRESS. ..- 
MARKER ADDRESS, 
PRIORITY BYTE, 
STATUS BYTE, | 
NAMESPTR ADDRESS. 
TASKSLINK ADDRESS,,. 
IPSTHREAD ADDRESS) '; 

Sinclude(:f1l:ipexch. elt) ,. & oe of 
_ DECLARE { PSEXCHANGES DESCRIPTOR LITERALLY ° STRUCTURE ( 
-.MSGSHEAD .ADDRESS 7 2 

' MSGSTAIL ADDRESS, 

TASKSHEAD ADDRESS, 

TASKSTAIL ADDRESS. 

NEXTSEXCH ADDRESS, 

RESERVED (10) BYTE, 

IPSTASKSHEAD ADDRESS, 

IPSTASKSTAIL ADDRESS) '; 

Sinclude (common. elt) 

DECLARE TRUE LITERALLY ‘@FFH'; 

DECLARE FALSE LITERALLY '@@H'; 

DECLARE BOOLEAN LITERALLY 'BYTE; 

DECLARE FOREVER LITERALLY 'WHILE 1'; 

Slist | 7 

2: I, al declare : 
aa address external; 


— 

Oxi 

t~ 
| 


16. 4 


li 


iru uuu 


-— 
ee) 
ee 


| 


22 1 IPWAIT: procedure ‘(eee sddedaic adores ech erat public; 


23 2 declare 
(exchSadr, delay, temp$msgS$ptr, lastStask$ptr) address, 
(temp$nsg based tempSmsg$ptr) msg$descriptor, 
(lastStask based lastStask$Sptr) ipStaskS$descriptor,. 
(exch based exchSadr) ipSexchangeSdescriptor, 
(task based RVACTV) ipS$task$descriptor; 


/* lock exchange data structure */_ 


24 2 call ieee 
25 2 if (tempSmsg$ptr: = exch. nage ceen then 
26 2 do; 
/* no message at exchange, queue. task up */ 
27 3 task. status=task.status Ok proce e: 3); 
28 3 lastStaskSptr=exch.ipStaskStail; 
29 3 lastStask.ipSthread, exch. Hyer cera =KQACTV; 
38 3 task. ipSthread=0; | | 
31 3 call unlock (7); | 
32 3 Call ROSUSP(ROQAC TV); 
33 3 vs return task.delay; 
34 3 end; 
35 2 else do; 
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/* There is a message here. Dequeue it and return 
its address */ 


if (exch.msgShead:= tempSmsg.link) =0 then 


36 3 

37 3 exch.msgS$tail=.exch; 

38 3 tempSmsg. link=tempSmsgSptr; 

39 3 call unlock (7); 

4g 3 return tempSusgS$ptr; 

4l 3 end; 

42 2 end; /* of procedure */ 

43 1 end IPWAIT; 

MODULE INFORMATION: a 

CODE AREA SIZE = OU F6H 2446D 
VARLABLE AREA STZE = UM OBH OD 
MAXIMUM STACK SIZE = OU@AH 10D 


133 LINES READ 
§ PROGRAM ERROR(S) 


Stitle( IPSEND routine, Version 1.3") 
1 IPSEND: | 


do; 
/* 
FEEEEE ELE FE FEET EFA L ELE E EEE EEE FEET ETEE EE EET EET E TPE + HHT 
PUBLIC PROCEDURE: IPSEND. LAST CHANGED 02/11/80 


This routine provides the interprocessor send facility. 

[f no tasks are waiting for the message, the message is 
queued on the exchange. If a task is waiting, it is taken’ 
off the queue, given the address of the message. and 
queued on the interprocessor exchange. 

Following this an interrupt is generated to 

signal the responsible pvrocessor that a task is ready. 


FAL EEEEEEEEEFEEEEEEEE ELEAF EEE EEEEEEFEFEFEEEFEEEEEEREF EEE ET 
* / a 


Sinclude (suspnd. ext) 
2 i. = ROSUSP: | | 
PROCEDURE (TSPYR) EXTERNAL; 


3 2 = DECLARE TSPTR ADDRESS; 
4 2 = END ROSUSP; 
Sinclude(insg. elt) — 
5 1 = DECLARE MSGSHDR LITERALLY 
= LINK ADDRESS, 
= LENGTH ADDRESS, 
= TYPE BYTE, 
= HOMESEXCHANGE ADDRESS, 
= RESPONSESEXCHANGE ADDRESS'; 


(o>) 
a 
tou 


DECLARE MSGSDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MSGSHDR, . 7 | Ls 
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REMAINDER (1) BYTE) '; 
Sinclude (:f1l:iptask.elt) 


DE LAYSLINKSFORWARD ADDRESS, 
DELAYS LINKSBACK ADDRESS, 
THREAD ADDRESS, 
DELAY ADDRESS, 
EXCHANGES ADD RESS ADDRESS 
SP ADDRESS, 
MARKER. ADDRESS, 
PRIORITY BYTE, 
STATUS BYTE, 
NAMESPYR ADDRESS, 
TASKSLINK ADDRESS, 
IPSTHRRAD ADDRESS) '; 
include (:£1: ipexch.elt) 
DECLARE A LITERALLY 
MSGSHEAD ADDRESS, 
MSGSTAIL ADDRESS, 
TASKSHEAD ADDRESS, 
TASKSTAIL ADDRESS. 
NEXTSEXCA ANDRESS 
RESERVED (10) BYTE, 
IPSTASKSHEAD ADDRESS, 
IPSTASKSTAIL ADDRESS) '; 
Sinclude (comon.elt) 
DECLARE TRUE LITERALLY ‘OFFH'; 
DECLARE FALSE LITERALLY ‘@@H'; 
DECLARE BOOLEAN LITERALLY ‘BYTE’; 
DECLARE FOREVER LITERALLY ‘WHILE 1'; 
Slist 


Sinclude (:£1: sema. ext) 


lock: procedure (sema$id) external; 


declare semaSid byte; 


end;. 


unlock: procedure (semaSid) external; 


declare sema$id byte; 
end; 


Sinclude (:£1:global. ext) 


/* Declaration of global inter-processor 
data structures */ 


declare 
procsid byte external, 
inySpid byte external, 
inSque address external; 
declare 
mySproc$id literally ‘mySpid', 
intSprocSexch literally ‘inSque’ 


setSint: procedure exteruady 
end setSint; 


’ 


DECLARE IPSTASKSDESCRIPTOR LITERALLY "STRUCTURE ( 


“STRUCTURE ( 


IPSEND: procedure (exch$ptr,msg$ptr) reentrant public; 


declare 


(exchSptr,msg$ptr, ast suausoer, taskSptr) address, 
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(exch based exchSptr) ipSexchangeSdescriptor, 
(msg based msgSptr) msg$descriptor, 
(last$Smsg based lastSmsg$ntr) tsg$descriptor, 
(task based taskSptr) ee eaeke se scriptor; 
jt ae access to ases Structures */ 
25 2 call eee 


/* check to see if any tasks are waveing */ 


26 2 if (taskSptr:= exch.,ipStaskShead)=09 then 
27 2 do; /* no tasks waiting; queue mesSaqe at 
28 3 lastSmsgSptr=exch.msgqS$tail; 
29 3 lastSmsg. link.exch,. poe Mae BeES 
30 3 msg. link=0; 
31 3 call unlock (7 V3 
32 3 7 return; 
33 3 end; 
34 2 else do; oy Es ; 
/* unqueue task and gang it ea. Svener processor */: 
35 3 if(exch. ipStaskShead: = task. ipSthread)= 8 then 
36 3 exch. ipStaskStail=exchSotr;: 
37 3 msg. link, task. delay=msg$ptr; 


/* queue task on the interprocessor exchange */ 


procSid= =shr (task. status.3) and 97H; 


38 3 

39 3 intSprocSexch= pie as 
49 3 task. ipSthread=0 ; 

41 3 call setSint; 7 

42 3 call unlock (7); ° 

43 3 return; 

44 3 end; 

45 2 end; /* of procedure "va 


46 


— 


end IPSEND; 


MODULE INFORMATION: 
CODE AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM STACK SIZE 
130 LINES READ 
0 PROGRAM ERROR(S) 


G1V8H 26 4N 
00 OOH 0D 
BOOCH — 12D — 


Stitle('set interrupt routine') 
1 SetSint: 


do; 
/* 
FEEL EEEEE FETE EL EE TET ETE ETE T THE THEE ET EET TE TEE ETE E EEE ETE 
“PUBLIC PROCEDURE: SEVTSINT, LAST CHANGED 2/11/80. 
Set interrupt routine. Generates a level 


four interrupt on the bus. The semaphore associated 
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~ with the: procsid field is: left set until the interrupt 
is. serviced.-.An semaphore, level 5, is set and uSed as 
Sas ZMGLCaT Oe that the eRe r EME ‘has been acknowledged. 


HEHEHE EEE EEE EEE HERE EEEE EEE EERE EEE EERE EE REE Hee 
*/ | A gee | 


Sinclude (:£1: global. ext). 4 
a Declaration of ee inter- processor 
data structures: */ —. : 


2 Ll = ee wtndie & | ie 
=  proc$id | byte stesenal: 
= - ay$pid byte external, 
=, inSque address external; 
3 l = declare 
= inyS procSid literally: ‘nySpid', 
= intSnrocSexch literally oe 
Sinclude (:£1: sema.ext) 
4 l = lock: procedure (semasid) external; 
5 2 = declare sema$id byte; | ak 
BZ sincendis >. | : 
7 1 = aioe procedure. (sema$id) external; 
3 2 == declare senaSid byte; - - & 
Y 2 = end 
19 1 setSint: procedure public; 


call lock (6) ; 


ll 2 
12 2 call lock (5); pes 
13 2 output (9 EBH) =9Fd; 
14 2 call lock (5); 
15 2 output (8EBH)=COEH; 
16 2 call unlock (5); 
17 2 call unlock (6); 
18 2 return; 
19 2 end; 

l 


end setSint; 


MODULE I[NFORMATTION: 


CODE ARBA SIZE 7 
VARIABLE AREA SIZE = O090U GD 
MAXIMUM STACK SIZE = 08602H 2D 


AS LINES READ 
WY PROGRAM BRROR(S) 


Stitle('IPACPT routine ) 
l IPACPT: 


: ‘ doe. 
]* 
FEF EF ELE FEEP EEE EE EEE TE EEL EEE EEE EE EEE EEE EEE EEE EE EE EET EP EE ++ 


PUBLIC PROCEDURE: IPACPT. LAST CHANGED 18/12/79 
“This routine implements the interprocessor accept facility. 
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If no message is queued at the exchange, a zero is returned. 
acall is made to IPWAIT to retrieve the first message 
on the queue. : 


Else, 


ALA EEAEE EE EEE EE EEE AE EEE EERE EEE EEE EE EEEEFEEEE EEE EEE EEE EEE 


MNP FRR e 


NON Fe 


ae 


Sinclude (suspnd. ext) 
RQSUSP:_ | | 
PROCEDURE (TSPYTR) EATERNAL; 
DECLARE TSPTR ADDRESS; 


END ROSUSP;: 

Sinclude (msg. elt) 

DECLARE MSGSYDR LITERALLY ' 
LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE BYTE, 

HOMES EXCHANGE ADDRESS, 
RESPONSESEXCHANGE ADDRESS'; 


DECLARE MSGSDESCRIPTOR LITERALLY STRUCTURE ( 
MSGSHDR, | 
REMAINDER(1) BYTE) '; 

Sinclude (task.elt) 

DECLARE TASKSDESCRIPTOR LITERALLY ‘STRUCTURE ( 
DELAYSLINKSFO RWARD ADDRESS, 2 
DELAYSLINKSBACK ADDRESS, 

THREAD ADDRESS, 

DELAY ADDRESS, 
EXCHANGESADDRESS ADDRESS, 
SP ADDRESS, 

MARKER ADDRESS, 

PRIORITY BYTE, 

STATUS BYTE, 

NAMESPTR ADDRESS, 
TASKSLINK ADDRESS) '; 

Sinclude (exch.elt) 

DECLARE EXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE 
MSGSHEAD ADDRESS, | 
MSGSTAIL ADDRESS, 

TASKSHEAD ADDRESS, 
TASKSTATIL ADDRESS, 


NEXTSEXCH ADDRESS) !'; 


Sinclude (common.elt) 

DECLARE TRUE LITERALLY ‘QOFFH'; 
DECLARE FALSE LITERALLY ‘@O9H'; 
DECLARE BOOLEAN LITERALLY 'BYTE'; 
DECLARE FOREVER LITERALLY ‘WHILE L'; 
Sinclude(:f1: sema.ext) 

lock: procedure (semaSid) external; 
declare semaSid byte; | 
end; » % % | 


unlock: procedure (semaSid) external; 
declare semaSid byte; | 
end; 

Slist 
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AL IPWAIT: ee eae delay) address external; 
ae bee declare (excnSadr,delay) address; .- 
2 end IPwAIT; 
1. IPACPT: procedure (exchSptr) address reentrant public; 
2 declare 
exchSptr address, : 
(exch based exchSptr) exchange$descriptor; 
2 call Lock (7): . = 
2 if exch.msgS$head = 0 then 
2 do; 
3 call unlock (7); 
3 return UW; 
3 end; ’ 
2 else do; 
3 call unlock(7); 
3 return PR WATECEXCRNDES) ass 
3 end; 
2 end; /* of procedure */ 
1 end IPACPYT; 
MODULE INFORMATION: 
CODE AREA SIZE = §93BH 59D - 
VARIABLE AREA SIZE = JO00d 0D 
MAXIMUM S'TACK..SIZE = 


OO 04H 4D 


Stitle('Level 4 interrupt handler’ ) 
Snointvector 
IntSproc: 
do; 


/* 


FHEFEEEEFEFETEL EP EL EET ETE EEE EEEEETE TEL EEE THESE ATE ESE EET EEE 


PUBLIC PROCEDURE: SETS$VEC$4, LAST CHANGED 2/11/86 


This routine Fields all level 4 interrupts. If the global 


procSid matches the local processor ID ROISND is called 


to awaken the intShnd task and the interrupt semaphore is 
Cleared. If the processor ID does not mat chy the interrupt 
is ignored. | 


EEE ECE ECE HCE EEE HE HET Ht Et ttt et 


*/ 
Snolist 


declare 
rql4ex (15) Bees SieSraaly 


setSvecS4: procedure interrupt 4 public; 


if procSid <> my$proc$id then 
call rqendi; 


2-160 AFN-01931A 


AP-88 


42 2 else do; 

43 3 procSid=0FFi; 

44 3 call unlock (5); 

A5 3 call rqisnd(.rql4ex); 
46 3 end; 

47] 2 return; 

48 2 end; /* of intSnroc */ 

49 uf end intSproc; 

MODULE INFORMATION: . 
CODE AREA SIZE = QM 2AH 42Nn 
VARIABLE AREA SIZE = UOGUH OD 
MAXIMUM STACK SIZE = OU@ALi 1@bd 
11@ LINES READ 
G9 PROGRAM ERROR(S) 

Stitle('’Interrupt dandler') 
1 IntShandler: 
do; 
/* 


FE EEEEEEEEEEEEEEEEEEE FEET EEE EE EEEEEEEEEEEATAEEEEEEFEE EEE EEE HEH 


LJ 


11 


PUBLIC PROCEDURE: INTSHANDLER. LAST CHANGED 2/11/86 


Interprocessor interrupt handler task. When notified by the 
SetSvec$4 routine that the InSqueue contains a task-message 
pair for this orocessor, the IntShandler task unqueues 

the task descriptor and resumes the task where it was 
Suspended. 


LF ALEEEEEEFEFEE FATE EE EE EPEE EEE EEE FEEEFEEEEEEEEEPEFEE TEE TEETH EEE ET 


lt 


tou a 


7, 


Sinclude(:fl:global.ext) 
/* Declaration of global inter-processor 
data Structures */ 


declare 
procsid hyte external, 
mySpid byte external, 
inSque address external; 
declare 
mySprocSid literally 'mySpid', 
intSprocSexch literally ‘inSque'; 
Sinclude (:£1:sema.ext) 
lock: procedure (semaSid) external; 
declare semaSid byte; 
end; 


unlock: procedure (semaSid) external; 

declare semaSid byte; s 4 

end; 

Sinclude (synch. ext) 

RQOSEND: 

PROCEDURE (EX CHANGE SPOINTER,MES SAGES POINTER) EATERNAL; 
DECLARE (EXCHANGES POINTER ,MESSAGESPOINTER) ADDRESS; 
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END ROSEND; 


ROWAIT: 


PROCEDURE (EXCHANGESPOINTER,DELAY) ADDRESS RXTERNAL; 


DECLARE (EXCHANGESPOINTER,DELAY) ADD RESS ; 
END RQWAIT; 


ROAC PT: 


PROCEDURE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 


DECLARE EXCHANGESPOINTER ADDRESS; 
END ROQACPT; 


ROISND: 
PROCEDURE (IEDSPTR) EATERNAL; 
DECLARE ILEDSPTR ADDRESS; 


END ROISND; 
Sinclude (common. elt) 
DECLARE TRUE LITERALLY '@OFFH'; 
DECLARE FALSE LITERALLY '@OOx'; 
DECLARE BOOLEAN LITERALLY ‘'BYTE'; 
DECLARE FOREVER LITERALLY. 'WHILE Ls 
oe Bae (eesune eee) 


RORESM: 


PROCEDURE (TSPTR) EXTERNAL; 
DECLARE TSPTR ADDRESS; 


END RORESM; 
Sinclude(:f£1: iptask.elt) 


DECLARE IPSTASKSDESCRIPTOR LITERALLY 'STRUCTYRE 


DELAYSLINKSFORWARD ADDRESS, 
DELAYSLINKSBACK ADDRESS, 
THREAD ADDRESS, 

DELAY ADDRESS, 
EXCHANGESADDRESS ADDRESS. 
SP ADDRESS. 

MARKER ADDRESS, 

PRIORITY BYTE, 

STATUS BYTE, 

NAMES PTR ADDRESS, 
TASKSLINK ADDRESS, 
IPSTHREAD ADDRESS) ';_ 


declare | 
rqli4ex (15) byte external; 


intShnd: procedure public; 


Geclare | 
(msgSptr, taskSptr) address ; 


do forever; 


nsgSptr=rqwait(.rql4ex,9) ; 

call lock(7); 

if intSprocSexch <> g er 
do; 
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4 taskSptr = intS$nrocSexch; 
4 intSprocSexch = JU; 
4 end; 
else . 
3 call unlock(7); 
3 call rgqresm(taskSptr) ; 
3 end; /* of do forever */ 
2 end; /* of task */ 
1 end intShandler; 
MODULE INFORMATION: 

CODE AREA SIZE = QU3DH §1N 

VARIABLE AREA SIZE = OU04H 4n 

MAXIMUM STACK SIZE = 80902H ‘ 2n 


1098 LINES READ 
0 PROGRAM ERROR(S) 


Stitle('Global Initialization. Version 1.1') 
globalSinit: 
do; 


/* 


FEE EEEEEEFEEEE EEE EEFEEEEEFEEEFEEEEFEEEEEEEEEEFEFEF EE EP EH EEE ETH $44 
PUBLIC PROCEDURE: GLOBALSINIT. LAST CHANGED 82/11/80 


This is an initialization routine that is called hy only 
one of the procesSoors in the system. It initializes those 
Structures that muSt be initialized before any [P routines 
are used and must then be left alone. 


FALE EEEEEEEEEEFEEEEREEEEEFEL EE EE EEEE EEL EEE EAL FFE EE EE EEE EAE HE TEF 
as 


Sinclude (:£1: ipexch.elt) 

DECLARE IPSEXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE ( 

MSGSHEAD ADDRESS. 

MSGSTAIL ADDRESS, 

TASKSHEAD ADDRESS. 

TASKSTAIL ANDRESS, 

NEXTSEXCH ADDRESS, 

RESERVED (10) BYTE, 

Ir STASKSHEAD ADDRESS, 

[PSTASKSTAIL ADDRESS) !; 

Sinclude(:£l1:global.ext) 

/* Declaration of global inter-processor 
data structures */ 


~ 
if 


declare 
 procSid byte external, 
mySpid byte external, 
inSque address external; 
declare : oe 
| nySprocSid literally 'nySpid', 
intSprocSexch literally ‘inSque'; 


acd 
il 
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1 declare 


ipSexchS$tab address external, 


ipSexch (1) ipSexchangeSdescriptor at(. ipSexch$tab), 


num$ipSexch byte external; 


1 declare semaphore(8) byte external; 
1 global$init: procedure public; 
2 declare i byte; 
/* initialization the int$procSexch queue */ 
2 intSprocSexch=0; 
/* initialize user ipeexch: decsrivtors ui 
2 do i=0 to num$ipS$exch-1l; 
3 ipseeni).. iostaeksneaases 
3 ipSexch(i). ipStask$tail=.ipSexch(i); 
3 end; 
f/* initialize procSid. field */ 
2 procSid=UFFH; 
/* initialize semaphores */ 
2 do i=) to 7; 
3 semaphore (i)=0@; 
3 end; 
2 return; 
2 end; 
1 end tone ey 
MODULE INFORMATION: 
CODE AREA SIZE = §9075H 117D 
VARIABLE AREA SIZE = O#BO1LH 1D 
MAXIMUM STACK SIZE = 00@2H 2D 


73 LINES READ 


Q@ PROGRAM ERROR(S) 


Stitle('LOCK and UNLOCK procedures, Version 1.1 ) 


ob 


/% 


MAs 
do; 


Ear Wee nt tT Ona O yw sO WO Wir TW Wt oon We OY OY ro wr UT iO on ron aE 


PJUBLI 


These 


C PROCEDURE: LOCK,UNLOCK, LAST CHANGED 10/12/79 


procedures provide mutual exclusion on access 


to global data structures used in the interprocessor 
communication package. Both routines use the seventh 


semaphore for global data and the sixth semaphore for 


interrupts. Software semaphores are used, 


EAEEEEEEEEEEEEEE EEE EE EEEEEEEEE EERE EEE EEEEEEEEEEEEEE EET ETE EET 
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* 
Sinclude (exch.elt) 
2 1 = DECLARE EXCHANGESDESCRIPTOR LITERALLY ‘*STRUCTURE ( 
MSGSHEAD ADDRESS, 
MSGSTAIL ADDRESS, 
TASKSHEAD ANDRESS, 
TASKSTAIL ADDRESS, 
NEXTSEXCH ADDRESS) '; 


ou 


Hou 


3 1 rqwait: procedure (exchSntr,delay$S$time) address external; 
4 2 declare (exchSptr,delay$time) address; 

5 2 end rqwait; 

6 a4 sSmask: procedure (mask) external; 

a 2 declare mask byte; 

8 2 end sSmask; 

9 ip declare tiimout exchangeSdescriptor external; 
19 HY declare sSemaphore(8) byte external; 

/* lock procedure called upon entry of code modifying 
data structures */ 

11 lL lock: procedure (semaSnum) reentrant vnublic; 
12 2 declare (semaSnum,s ema) byte; 
13 2 declare (memSptr) address; 
14 2 Sema=l; 

15 2 do while sema=1; 
15 3 memSptr=rqwait(.timout,1l); 
17 3 call sSmask (®@CQ@H) ; 

18 3 sema=semaphore(semaSnum) ; 
19 3 semaphore (semaS num) =OF Fi; 
20) 3 call sSmask (@4@h) ; 
21 3 end; 

22 2 return; 
23 2 end; /* of LOCK */ 


/* unlock called to exit region */ 
24 1 unlock: procedure (semaSnum) reentrant public; 
25 2 declare semaS$num byte;- 


2 semaphore (semaSnum)=6;_ 
27 2 return; i 
2 end; /* of unlock #*/ 


29 1 end SEMA; 


MODULE INFORMATION: 
CODE AREA SIZE = YOSFH 95D 
VARIABLE AREA SIZE GOOSH OD- 
MAXIMUM STACK SIZE 90 96H 6D 
67 LINES READ 
§ PROGRAM ERROR(S) 
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Stitle('{LPSINIT initialization routine’ ) 
IpSinit: 


do; 
/% | | 
EE HECEEE CECE HEE EEECEEECEECEEEEEEEEEEEEEEEEE EEE EEEHEE EERE 


PUBLIC PROCEDURE: IPSINIT. LAS T CHANGED 19/11/79 


Initialization routine. Creates ROL4EX, initializes 
the interrupts and the interrupt handlers and creates 
the interrupt task intShnd. 


CHECECEE HEE HEEE EEE EEE EEE EEE EEEEEEE EE EE HEE EE EEE EE EEE EHH EH 
ay 


Sinclude(:f1l:glohal. ext) : 
/* Declaration of global inter-processor 
data strictures */ 


il 


declare 
procsSid byte external, 
mySpid byte external, 
inSque address external; 
declare 
nySprocSid literally ‘mySpid', 
intSprocSexch literally “inSque'; 
Sinclude (:f1:sema.ext) 7 
lock: procedure (semaSid) external; 
declare sema$id byte; 
end; 


a 
i 


-— 
Woh 


lod a a 


unlock: procedure. (semaSid) external; 
declare semaSid byte; 

end; 

Snolist 


Nh 
ow at 


1 intShnd: orocedure external; 
2 end intShnd; 


hg setSvec$S4: procedure external; 
2 end setS$vecs4;. 3 | 


1 .. declare 
intShnd$stl literally '60', 
intShndSstk (intShndS$stl) byte, 
intShndStd (20) byte, 
rqli4ex (15) byte public, 
intShndSpri literally '65'; 


iE declare intShnd$s td staticStaskSdescriptor data ( 
‘inthnd', 
intshnd, 
tae onnas eek, 
intShnd$sti, 
intShndSopr i, 
d, - 
.intShndste ); 
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inpSinit: procedure public; 


/* wait for Someone to perform global 
and reset semaphores */ 


call lock(7); 
call unlock (7); 


output (GEBH) =80H; 
output (GEBH)= 9EH; 
call rgqcxch(.rgl14ex); 


call rqctsk (,intShnd$std); 
call rgsetv(.set$vec$4,4); 


call rqelvl (4); 
return; 
end; /* of procedure */ 


end ipoSinit; 


MODULe& INFORMATION: 


CODE AREA SIZE 
VARTABLE 
MAXIMUM STACK SIZE 
133 LINES 


O80 3DH 61D 
AREA SIZE = UOSFi 95D 
= §002H 2D 


READ 


PROGRAM ERROR(S) 
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[RRR KKK RRE KKK KEKE RE KK KEKE KR KEKKRER RK KKK KERR ERR ERKEKREREKKEKEKEKK KKK KEKE 


* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
*k 
k 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 
* 


1 


A CWUMANUNKA Wa; 


aan 


ll 
12 


13 


14 
LS 
16 


17 
18 


T OE 
INTERFACE 


MULTI-~PROCESSOR WORLD. 


TERMINAL HANDLER REQUESTS: 


DISK 


READSTYPE = 8 
WRITESTYPE 212 
I/O SYSTEM REQUESTS: 
DFS SRD ~— ad oP 
DFSSwt = 76 
DES SSK = 77 
DFS SCLS = 78 
DFSSOPN = 79 
BASIC TASK COMMAND REQUESTS: 

SUSBAS = 128 
RESBAS = 129 


a ee ee 


BIPpI 
TYIS IS THE INTERFACE BREWEEN THE RMX/BASIC PROCESSOR AND 
THE RMX /BASIC INTERPORCESSOR 
(BIPL) INTERFACES TO THE TERMINAL HANDLER AND 
THE DISK IO SYSTEM. THR BIPI SUPPORT THE RECRIPT OF THE 
FOLLOWING MESSAGE TYPES: : 


BIPISMODULE: DO; 


READ FROM TERMINAL 
WRITE TO TERMINAL 


READ FROM DISK 
WRITE TO DISK 

DISK SERK OPERATION 
DISK FILE CLOSE 
DISK FILE OPEN 


SUSPEND BASIC ‘TASK 
RESUME BASIC TASK 


THE TASK WILL BE ENTERED BY SENDING THE NORMAL REQUEST MES- 


SAGE TO THE GLOBAL EXCHANGE BIPISEXCH, 
FR KK IK RIK KR RIK IK RI RIK KK RIK IRR IKK IK IK IKK HK KKK RAKE KEK AKER 


/* DEFINE THE LITERALS */ 


DECLARE READSTYPE LITERALLY '8'; 


DECLARE WRITESTYPE 
DECLARE DFSSRD LITERALLY '72' 
DECLARE DFSSwT LITERALLY '756' 


LICERALLY '12'; 


=e Te 


DECLARE DFSSSK LITERALLY '77'; 


DECLARE DFSSCLS LITERALLY ‘'78'! 
DECLARE DFSSOPN LITERALLY 79' 
DECLARE SUSBAS LITERALLY 
DECLARE RESBAS LITERALLY '129' 


£128! 


=e me MO Ne 


/* DECLARATION OF INTERNAL VARIABLES */ 


DECLARE (MSGSPTR,RESPONSESPTR) ADDRESS; 


DECLARE (TYPE) BYTE; 


/* DEFINE RMX PROCEDURES USED BY TilE TASK oy 


ROSEND:. 


PROCEDURE (RXCHSPTR,MESSAGESPTR) EXTERNAL; 
DECLARE (EXCHSPLIR,MESSAGESPTR) ADDRESS; 


END RQSEND; 
ROQWAIT: 


PROCEDURE (BXCHSPTR,TIMEOUT) ADDRESS EXTERNAL; 


DECLARE (EXCHSPTR,TIMEOUT) ADDRESS; 


END RQWAIT; 
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36 


42 


ENS 


le 


Hou uw tt tl 


RQOSUSP: — 
PROCEDURE 
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(TASKSDESCSP'ER). EXTERNAL}. 


DECLARE UTes he PESGee th) ADDRESS; 


END ROBUSR? 


- RQRESM: 


PROCEDURE 


Cf 


(TASKSDESC$PTR) EXTERNAL; 


DECLARE (TASKSDESCSPTR) ADDRESS; 
END RORESM; 


/* DEFINE INTER-PROCESSOR Pee en DEnee USED . 
BY THE TASK */ 


EPSEND: 
PROCEDURE 


(EXCHSPTR,MESSAGESPTR) EXTERNAL; 


DECLARE (RXCHSPTR ,MES eae ADD RE SS j 


END IPSEND; 
IPWAIT: | 
PROCEDURE 


i 


(EXCHSPTR, DUMMY) ADD RESS @X'TERNAL; 


DECLARE (BEXCHSPTR,DUMMY) ADDRESS 
END IPWAIT; 


IPINIT: 
PROCEDURE 


EXTERNAL; 


END IPINIT; 


SETSVECS4: 
PROCEDURE 


EXTERNAL; 


END SETSVECS4; 


/* DEFINE ‘THE EXCHANGES REQUIRED BY 


THE TASK 


SINCLUDE (:Fl: 


"7 
:EXCH DEF) 


DECLARE EXCHANGESDESCRIPTOR LITERALLY > CT NRS ( 


‘DECLARE 


BIPISRE EXCHANGESDESCRIPTOR EXTERNAL; 


/* DEPINE THE BASIC MESSAGE STRUCTURE OF 
INCOMING MESSAGES */ 


‘DECLARE 


LINK q 


LENG 


MSG © “BASED. MSGSPTR STRUCTURE ( 
Oe ; ADDRESS, 


TH | ADDRESS, 
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MESSAGESHEAD ADDRES 
MESSAGESTAIL | ae 
TASKSHEAD | | - ADDRESS, 
-TASKSTAIL —.—_—__..._ —- ADDRESS, 
EXCHANGESLINK. |. ADDRESS )'; 
= DECLARE INTSEXCHANGESDESCRIPTOR LITERALLY "STRUCTURE ( 
= ME SSAG ESHEAD - - ADDRESS, | | 
-MESSAGESTAIL ..... — ADDRESS, 
. TASKSHEAD ADDRESS, 
- TASKSTAIL | . ADDRESS, 
EXCHANGESLINK ADDRESS, 
LINK. - wt, <, ADDRESS, 
LENG TH —, s ADDRESS, 
TYPE. « » BYTE. ) 03 
DECLARE BIPISEX EXCHANGESDESCRIPTOR EXTERNAL; © 
DECLARE RQINPX., EXCHANGESDESCRIPTOR EXTERNAL; 
DECLARE ROOUTX EXCHANGESDESCRIPTOR EXTERNAL; 
DECLARE ROOPNX EXCHANGESDESCRIPTOR EXTERNAL; 
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TYPE 7 BYTE, 


HOMBSEXCHANGE ADDRESS. 


RESPONSESEXCHANGE ADDRESS _ ); 


/* DEFINE LOCATION OF 'BASIC' TASK DESCRIPTOR 


DECLARE BASCSTD ADRESS EXTERNAL; 


/* BEGINNING OF BIPI PROGRAM PROCEDURE */ 


BIPI: 
PROCEDURE PUBLIC; 


/* AT INITIALIZATION WAI? FOR COMMUNICATIONS 
PROCESSOR TO COME UP */ 


/* 


/* 


/* 


/* 


/* 


/* 


/* 


MSGSPLR = ROWATI(.BIPISRE, 100); 
CALL IPSINI‘T; 


WAIT 


SWAP 


SAVE 


TEST 


TRST 


FOR A REQUEST FROM A PROCESSOR ON BUS 
MSGSPTR = IPWAIT (.BIPISEX,9); 
RESPONSE ADDRESSES FOR LATER USE * / 


RESPONSESPTR = MSG.RESPON SESEXCHANGE; 
MSG.RESPONSESEXCHANGE = .BIPISRE; 


MESSAGE TYPE FOR TESTING */ 
TYPE = MSG.YPE; 
FOR A READ REQUEST FROM TERMINAL */ 


IF TYPR = READSTYPE 
THEN CALL ROSEND (.ROINPX,MSGSPTR); 


FOR A WRITE REQUEST TO TERMINAL */ 


IF TYPR = WRITESTYPE 


THEN CALL ROSEND (.RQOUTX,MSGSPTR);.- 


a 


*7 


CONVERT REQUEST TYPE TO DISK COMPATIBLE TYPE */ 


If TYPE > 71 
THEN MSG.TYPE = MSG.TYPE —- 64; 


HANDLE OPEN DISK FILE REQUEST */ 


IF TYPE = DFSSOPN 
THEN CALL ROSEND (.ROOPNX, MSGSPTR) ; 


SUPPORT ALL OTHER REQUEST TYPES FOR DISK I/0 */ 


IF ((TYPE > 71) AND (TYPE < 79)) THEN 


CALL ROSEND (MSG.HOMES EXCHANGE,MSGSPTR); 
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/* SUPPORT REQUESTS FOR 'BASIC' TASK OPERATIONS */ 


62 3 IF TYPE > 127. 
THEN DO; 


/* SUSPEND TASKS IN OPERATION */ 


64 4 IF TYPE = SUSBAS - 
| THEN CALL ROSUSP (BASCSTD) ; 


/* RESUME TASKS INTO OPERATION */ 


66 4 IF TYPE = RESBAS 
| ' THEN CALL RQRESM | (BASCSTD) ; 


68 4 END; 
/* WAIT FOR RESPONSE FOR NON-'BASIC' OPERATIONS */ 
69 3 ELSE MSGSPTR = RQWAIT (.BIPISRE, 9); 


/*® SWAP RESPONSE EXCHANGES AGAIN BEFORE 
RETURNING MESSAGE */ 


70 3 | _ MSG.RESPONSESEXCHANGE = RESPONSESPTR; 
/* RETURN THE MESSAGE TO TYE CALLING PROGRAM */ 
71 3 | CALL IPSEND (RESPONSESPTR, MSGSPTR); 


/* END OF TASK */ | 


72 3 END; 
73 2 END BIPTI; 
74 l END BIPISMODULE; 


MODULE INFORMATION: 


CODE AREA SIZE O1G1H 257D 
VARTABLE AREA SIZE 08 O05i 5D 
MAXIMUM STACK SIZE = @002H — 2D 
206 LINES READ 

§ PROGRAM ERROR(S) 


it 
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INTRODUCTION 


System designers are satisfying more and more difficult 
application needs with solutions which use microproces- 
ors in a distributed environment. This distribution of 
intelligence results in many system benefits, including a 
simplification of the design and a resulting decrease in 
the development time of the system solution. An addi- 
tional feature is the minimization of the installation 
costs of the system resulting from reduced wiring and 
from resource sharing. However, to effectively create 
distributed solutions, a reliable communication scheme 
must be used which links the various parts of the solu- 
tion together. 


The purpose of this application note is to demonstrate 
the ease with which Intel iSBC™ boards can be config- 
ured to implement distributed solutions. Several ap- 
proaches are offered which apply standard operating 
modes of both the hardware and of the software. While 
certainly not the only solution, a distributed processor 
communications protocol is developed which will sup- 
port many typical applications. 


Distributed systems generally fall into one of two cate- 
gories. The first consists of those systems in which the 
processors are located in such a manner as to allow com- 


munications over a common system data bus, such as 


Intel’s MULTIBUS™ system bus. The second category 
involves systems in which the processors are also geo- 
graphically distributed. This class of system generally 
uses a form of serial communications to allow each pro- 
cessor to communicate with other processors in the 
system. 


The emphasis of this application note is on serial multi- 
processing links. Before proceeding with a development 
of application solutions which involve serial communi- 
cations, this note includes a short discussion of common 
network designs. | 


Common Network Designs 


Serial networks may be classed into three general cate- 
gories. These are the LOOP, the MULTIDROP, and 
the STAR. Each has applicability to certain iSBC prod- 
ucts and has distinct advantages and disadvantages in an 
application, After discussing the characteristics of each 
network, an application scenario illustrates their uses. 


LOOP NETWORKS 


The loop represents the most common of the communi- 


cation schemes. It is derived from the older teletype 


communication networks in which several printers were 
connected in series: Any data generated on one machine 
causes all machines concerned in the network to echo 
the data. This arrangement is shown in Figure 1. Loop 
communications normally use a 20-milliamp signal to 
convey the data. The presence of this current, known as 


marking, represents a binary | and the absence, or spac- 
ing, of any circuit (an open circuit) represents a binary 
0. Both full and half duplex configurations are com- 
monly used. 


Figure 1. Serial Loop Configuration 


The incorporation of loop networks into a system im- 
plementation creates both advantages and disadvan- 
tages. The strongest argument for using a loop is the 
inherent noise immunity which can be gained by using 
the 20-milliamp current to convey the data. The use of a 
high compliance voltage also allows the transmission of 
data for large distances at low to moderate transmission 
rates. 


Solid state circuits common to current technology are 
somewhat less reliable than older mechanical units when 
many stations are configured onto the loop. This is the 
result of the requirement to reproduce the information 
at each node for transmission to the next node. If any 
node fails, all other nodes downstream in the communi- 
cation network will not be capable of communicating. 
Even with this constraint, many good designs incorpo- 
rate the loop network concepts. 


MULTIDROP NETWORKS 


Multidrop networks are fast becoming the accepted net- 
work for multiprocessor communications. This type of 
network is shown in Figure 2. As can be seen, this ar- 
rangement is similar to that of the loop. The advantage 
is that all stations are capable of receiving data simulta- 
neously. Multidrop networks are voltage driven since to 
pass current through a node creates a loop situation. 
The electrical interface for multidrop networks consists 
of tri-state drivers and high impedance receivers. The 
RS422 electrical interface is common for this type of 
network since it provides high speed data transmission 
over long distances with good noise immunity. 
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Figure 2. Multidrop Loop Network 


The ability to implement networks with a minimum 
amount of hardware and the potential expansion capa-_ 


bilities provide the multidrop network with a significant 


advantage in many applications. Since each node in the. 


network can be.added by simply adding another tee net- 
work, expansion is performed without the need for 
modification of the communication network. 


Intel’s iSBX 351™ Serial MULTIMODULE™ Board i is 


an ideal vehicle for the implementation of multidrop. 


networks. Its use is detailed in subsequent paragraphs of 
this application note. 


STAR NETWORKS | 
Star networks are implemented where either data 
throughput or hardware limitations prohibit the use of 


other types of communication arrangements. Figure 3 


illustrates a typical star network implementation. Note 
that a star network is really an example of multiple 
point to point communications. System throughput is 
improved since communication can occur with all slave 
nodes simultaneously without the need to have each 
node monitor iraffic. which is not. intended for it. 


Figure 3. Star Configuration ; 


Intel’s iSBC 544™ Intelligent Communications Con- 
troller and the iSBC 534™ Four- Channel Communica- 
tions Board are ideal choices to design star communica- 
tions networks. The outer points of the star are im- 
plemented using any single board computer which has 
on-board serial communications. An example of this 
type of network i is included i in this application note. 


Sample Application | 


An application example is used in this application note 
to illustrate the techniques which are required to imple- 
ment various types of serial communication networks. 
Both hardware and software aspects of the design are 
described in some detail. 


The application discussed i in this note involves the crea- 
tion of an alarm and security system, for a multiple 
building complex.. This. complex is shown in Figure 4. 
The solution generated allows monitoring of three exist- 
ing buildings with provision for the addition of a fourth 
at a later date. The figure shows that each building is to 
have a local annunciator panel for reporting activity in 
those areas served by the building sensors. In addition, a 
main security station provides monitoring of all build- 
ings in the complex. 


PART TIME 
SECURITY STATION 


PART TIME 
SECURITY STATION . 
[7 _ end ua 


"BUILDING #4 


(FUTURE) BUILDING #3 


CAFETERIA 


SECURITY PART TIME 
‘STATION : SECURITY STATION 


ENERGY CENTER 


BUILDING #1 BUILDING #2 


_ Figure 4. Application Building Complex 


Applications such as this are optimized by distributing 
the system intelligence throughout the complex. This 
serves two needs; that of minimizing the. wiring costs, 
and of providing.an improvement in system reliability. 
When a system is distributed in this way,.a means must. 
be devised which allows communication. between the 
various elements of the network. Both hardware net-. 
work design and software communication protocol are 
required before: ime system, can be considered opera- 
tional. ae - | 
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In order to illustrate various network designs, the exam- 
ple is broken into a distributed system as shown in Fig- 
ure 5. This is an example of a multidrop communication 
network. The system design does not require that build- 
ing nodes communicate with each other; all communica- 
tions are between building annunciator nodes and the 
main operator station. This illustrates the concept of a 
master and a slave. This will be further discussed in a 
later portion of this application note. 


BUILDING #4 BUILDING #3 BUILDING #2 BUILDING #1 


SENSORS SENSORS SENSORS SENSORS 
myrary etary A 5 ase 
ldtsts td tad 
tol 14 

toed 1otol 
prtt-iit 
| BUILDING 
| 


ANNUNCIATOR 
| 
MAIN . > 
OPERATOR PRINTER 
STATION 


Figure 5. A Multidrop Application 


The building annunciator can be further distributed as 
shown in Figure 6. Here, a star communication network 
is created which places data gathering intelligence near 
clusters of sensors. These stations, or nodes, then trans- 
mit information regarding local activity to their master 
node, the building concentrator/annunciator panel. 
Note that this panel serves both as a master node for the 
sensor units and as a slave node for the main operator 
station. This arrangement is common in many system 
designs. 


SENSOR SENSOR SENSOR 
CLUSTER CLUSTER CLUSTER 


¢ THE USER OF CLUSTER 
SENSOR INTERFACE 
CONCENTRATORS 
MINIMIZES 
WIRING COSTS 
* HIGH SPEED SERIAL 
SENSOR SENSOR SENSOR LINKS REPLACE 
INTERFACE INTERFACE INTERFACE 
CONCENTRATOR CONCENTRATOR 


MULTIPLE SENSOR 

CONCENTRATOR WIRING 

¢ SYSTEM INTEGRITY IS 
ENHANCED BY LOCAL 
DECISION MAKING AT 


COMMUNICATION 
NODES 


CONCENTRATOR 
ANNUNCIATOR 
PANEL MAIN 
OPERATOR 
SERIAL LINK STATION 
TO MAIN 
SECURITY STATION 


Figure 6. A Star Application 


HARDWARE IMPLEMENTATION 


The implementation of communication networks using 
iSBC boards for both star and multidrop techniques is 
detailed in the following sections. In each case, a 
master/slave relationship is assumed. For purposes of 
illustration, actual data from the application example is 
used in performing the sample calculations. While not 
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the only possible system designs, those shown are con- 
sidered to be typical and should enable the reader to 
gain an insight into techniques which can be used to 
create similar designs. 


Star Network Design 


A star network can use almost any accepted transmis- 
sion media. This is because each node communicates 
with only one other node, creating a multiple point to 
point link. Since the techniques are identical for all 
media, this note discusses only a representative exam- 
ple. RS232C data transmission is used to demonstrate 
the techniques which can be used to establish a star net- 
work. 


The heart of a star network is the master node. It must 
provide a means of independent communication with 
each of its slave nodes. Costs can be minimized if multi- 
ple communication drivers are placed onto the same 
board. The example chosen requires that four slave 
nodes be controlled by the master. The iSBC 544 Intelli- 
gent Communications Controller provides this func- 
tion. It provides a software selectable baud rate and the 
ability to offload the host processor of communication. 
activities. If additional slave nodes are required, the 
system can be expanded by adding iSBC 544 controller 
boards. | 


An ideal choice for a slave node is the iSBC 80/10B™ 
Single Board Computer. This computer provides good 
processing capabilities with low cost. It includes both an 
RS232C and 20-milliamp current loop communications 
interface. For many small applications it makes an ideal 
choice for a complete single board solution. 


Figure 7 shows the implementation for a four-node plus 
master star communication network for the security ap- 
plication. Both the iSBC 544 communications board 
and the iSBC 80/10B Single Board Computer require 
jumpering and component insertion to allow operation 
in either the RS232C mode or in the EIA mode. EIA 
operation is electrically identical to RS232C but has 
specifications which allow transmissions at significant 
distances when the baud rate is reduced. For the pur- 
poses of this application note, the terms are used inter- 
changeably. 


iSBC 80/10B™ 
| SINGLE BOARD 


'SBC 80/108™ 
SINGLE BOARD 


iSBC 80/10B™ 


SINGLE BOARD SINGLE BOARD 


COMPUTER COMPUTER COMPUTER COMPUTER 


: MULTIBUS™ SYSTEM BUS 


Figure 7. Star Implementation 
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In the case of the iSBC 544 board, a header plug can.be 
inserted into an on-board connector to enable the cor- 
rect mode of operation. The wiring for this header is 
shown in Figure 8. Note that the ready to send and the 
clear to send signals are jumpered to allow the correct 
operation of the USART without the control signal of a 
modem. Also note that the transmit and receive signals 
are reversed through the header. 


TON 


. DTE TxC 
DSR 
DTR 
CTs 
RTS 
‘RxD 
TxD 
STxD 


SRxD 


Figure 8. Master to Master Wiring Header. 


The use of an RS232C signal for long distance com- 
munication necessitates the use of a low baud rate for 
reliable data transmissions. This is shown in Figure 9. 


“METERS / FEET 


_ 
oe 
oS 


X— CABLE IS 22 AWG 
4-CONDUCTOR (QUAD) 
. INSIDE STATION WIRE 
DEC P.N. 9105856-04. 


DISTANCE (LOG SCALE) 
3 z 


O—CABLE IS TWO 22 AWG 
TWISTED PAIRS EACH 
SHIELDED IN BELDEN 8777 
(THREE PAIR). 

DEC P.N. 9107723. SHIELDS 
TIED TO GROUND. 


110 150 300 600 1200 2400 


DATA RATE IN BAUD (LOG SCALE) 
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The security system application design allows for mini-. 
mum. communication traffic so a baud rate of. 1200 is 
used for the star networks. The placement of intelli- 
gence at the sensor cluster minimizes the amount of data 
which must be transmitted, providing adequate re-_ 
sas time at this. data rate. ~ 


The pueda ae sie includes the selection of the 
communication scheme to be used between the host pro- 
cessor and the slave node. Fortunately, this task is 


simplified by the use of built-in master/slave protocol 


functions contained on the iSBC 544 communications 
board. These functions involve three hardware features. 
The first is the incorporation of dual-ported memory 
onto the board. This memory provides a media for the 
storage of data and commands for communication be- 
tween the slave and the host processor. The second 
feature generates a flag interrupt each time the host 
board writes into the first location of the dual-ported 
memory. The interrupt is cleared when the memory lo- 
cation is read by the slave processor. Finally, the execu- 
tion of the 8085A- 2 SOD instruction generates a MUL- 
TIBUS interrupt to inform the host.board of the need to 
service the slave. This interrupt can be vectored to the 
host interrupt matrix to activate a service routine in sup- 
port of the slave board... .- 3 


A detailed explanation of the : use s of these features is 
found in another application note, AP-53, Using the 
iSBC 544™ Intelligent Communications Controller. 
The reader should refer to this document for details of 
the board and its use. 


fe agit | SHIELDED | UNSHIELDED 
_| BAUD | (IN FEET) (IN FEET) 


ALL DISTANCES SHOWN ARE MORE THAN 
50 FEET/2500 pF, HENCE THESE 
TRANSMISSIONS VIOLATE RS232C. — 


NOTE THAT THE “EIA” INTERFACE CASE, 


SHIELDED PAIR OUT-PERFORMED 
__ UNSHIELDED WIRE. 


9600 


Figure 9. RS232 Baud Rate vs Distance _ 
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Multidrop Network Design — 


The complexity of a multinode system is minimized 
through the use of a multidrop network. Certain limita- 
tions are placed on the acceptable hardware transmis- 
sion media in multidrop applications. A scheme must be 
used which allows each of the nodes to alternatively gain 
control of the network in order to communicate its 
message. . 


Both half and full duplex configurations are allowable 
in a multidrop network. While it is simpler from a hard- 


ware standpoint, a half duplex connection requires. 


more stringent communications protocol as this system 
allows communications in only one direction at a time. 
For all practical purposes, no priority for masters or 
slaves is provided. All nodes may listen to whomever is 
using the line at the time. The software must be written 
to allow only one node to communicate at a given 
instant. An example of a half duplex network is the 
Ethernet. 


More straightforward software can be written for full 
duplex communication configurations. In this instance, 


HEADERS 


XU4 AND XUS5 . BUFFER U1 
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an assumption is made that only one master is config- 
ured into the system and always drives the output lines. 
Any number of slaves can be placed to drive the input 
lines, communicating only when queried by the master 
node. This is the scheme used for the application exam- 
ple which is discussed in this application note. 


Intel’s iSBX 351 Serial MULTIMODULE Board lends 
itself well to a multidrop application. It allows a wide 
variety of system solutions to be created using any of the 
single board computers which incorporate iSBX bus 
connectors. Several board options must be enabled to 
create the multidrop communications configuration. 


The first option involves configuring the drivers to.use a 
tri-state driver on the output lines. This allows only the 
board desiring to control the communications signals to 
place data on the serial output lines. The board config- 
uration is different for a slave and for a master node. In 
the Intel implementation, the driver output signal lines 
are controlled using the DTR (data terminal ready) 
signal from the USART. The jumper configuration for 
both a slave and a master is shown in Figures 10 and 11. 


HEADERS 


BUFFER U2 XU4 AND XUS 


HEADERS 
XU4 AND XU5 


iSBX 351™ SERIAL MULTIMODULE™ BOARD 


Figure 11. Slave Configuration Detail 
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Figure 12 illustrates the physical wiring data paths 
which are used to. create a full duplex multidrop net- 
work having a master and four slave stations. Each 
board must be configured using a header block to pro- 
vide the correct. signals. This t is done as shown in Figures 
10 and 11. | 


Finally, bias resistors are chosen to terminate the serial 
communication data paths. A discussion of the formu- 
las for determining the correct values for the two 
resistors is provided in Appendix A of the iSBX 351™ 
Serial MULTIMODULE Board Hardware Reference 
Manual (Order Number 9803190). If the equations are 
solved for the componnts used on the RS422 section of 
the board, the equations for calculaning the correct 
values become: 


ny RbI = 4500 / (18.6 _ 1.6n) 
anes is the number of slave nodes | 
AND | 
Rb2 = 2500 / (18.6 — 1.6n) 
where n is the number of slave nodes. 


The drivers used on the iSBX 351 communications 
MULTIMODULE board limit the number of slave 
nodes to 11 for any one network. If greater numbers of 
nodes are required, a driver component substitution 
may be required. 


For the example application in this note, four slave 
nodes are used, so the calculated resistor values become 
370 ohms for Rb1 and 205 ohms for Rb2. 


Figure 13 illustrates the acceptable baud rates for vari- 
ous communications cable lengths using the RS422 in- 


BIAS RESISTORS 
ON THE INPUT LINES 
TO THE MASTER 


MASTER 
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terface. The iSBC 351 board is designed to support data 
transmission rates of up to 19.2 kilobaud. Thus, the 
system designed using these boards is seen to permit a 
total multidrop cable length of up to 4000 feet (1. 219 
km). The sample application’ discussed in this note in- 
corporated a total communications link length of 1600 
feet, well within the performance limits. | 
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Figure 13. RS422 Data Rate vs Distance 


SOFTWARE IMPLEMENTATION 


Once the hardware has been defined, the design process 
moves into a software phase. Here, protocols are de- 


‘fined which provide both data transmission and hand- 


shaking between nodes. Handshaking is defined as 


background communication which maintains synchro- 


nization and integrity of the communications link. 


SLAVE 2 


iSBX 351™ SERIAL 
MULTIMODULE™ 
BOARD 


ISBX 351™ SERIAL 
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Figure 12. Master/Slave Physical Wiring 
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Again, standard features of both iSBC board products 
and of iRMX™ software products simplify the incorpo- 
ration of communication protocols into the system solu- 
tion. 


Master/Slave Relationships 


In order to maintain an orderly flow of data between 
nodes, software must be created which allocates priority 
and only allows one node to transmit at any instant. The 
most straightforward technique which incorporates this 
function is the master/slave relationship. Here, one 
node is designated as a master and all others are slaves. 
Each slave is allocated a time during which it may trans- 
mit any information to other nodes. The master node 
controls the prioritization of all slave nodes. The com- 
plexity of the system can be further reduced if a full 
duplex scheme is implemented. In this mode, all slaves 
listen only to the master and transmit their messages 
over a common serial channel to the master. A disad- 
vantage of this technique is that direct slave to slave (vir- 
tual channel) transmissions are not permitted. 


Figure 14 shows how a master node establishes time 
slots for windows, during which a slave may control the 
output channel and transmit data to the master. Each 
slave node is assigned a unique identification or address. 


QUERY QUERY QUERY 
SLAVE 1 SLAVE 2 SLAVE 3 


MASTER [- >| | | | 
WINDOW: 


SLAVE 1 . 


SLAVE 2 
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Figure 14. Generation of Windows 
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Each data packet contains an address as an integral 
part. When a slave recognizes its address in the packet 
from the master, it knows that it has fixed time window 
in which to return its own data packet to the master. 


Data Packet Formats 


Communications between each slave and its master in- 
volve the transmission of data packets. Each packet 
contains both handshaking information (such as check- 
sums and message counts) and the information which is 
to pass between nodes. The handshaking portions of the 
message are used to maintain the integrity of transmis- 
sions in the face of such external stimuli as electrical 
noise. | : 


Debugging and system maintenance is minimized when 
a means is provided which allows easy viewing and in- 
terpretation of the communication messages. The 
scheme used in this application note uses a fully ASCII 
compatible communications format. This allows a CRT 
terminal to tap onto the link and to monitor all com- 
munication messages. : 


Each message packet begins and ends with a unique 
character. This character cannot exist with a message 
block. Using the ASCII formats, all messages use the 
numeric representation of 0 to 9 and the alpha charac- 
ters from A to Z. A line feed is used to begin a message 
packet and a carriage return is used to terminate the 
message. The assignment of these characters assures an 
easily interpreted message packet. 


The layout of the data packet is shown in Figure 15. The 
justification and description of each field is given in the 
following paragraphs. Note that much of the message is 
concerned with maintaining system integrity. The re- 
quirement for an address field has already been de- 
scribed. Two characters are used for this field and pro- 
vide for 256 addresses (O-FF hex). The protocol being 
described used 0 as the system master and 1 through 255 
for possible slave addresses. | 


‘CHECKSUM | ENDCHAR 
(0-FF) (CR) 


EXTENSION | | TASK 


(6 CHAR) DATA 


*THE LENGTH (IN BYTES) OF THE DATA FIELD 


Figure 15. Communications Packet Format 
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The next field indicates the type of message being sent 
and the action which is required by the receiver. Anal- 
ysis of system communication requirements indicate 
that five message types are sufficient. The use of a single 
byte of the packet for this field allows a total of 16 
message types. This leaves 11 for future expansion. The 
types being used i in ans ePpucsnon: are: 


_ Type 0 — Thisisa reset request from the master to » 

-a Slave. It will cause the target slave to generate a 
software reset. This command is used only when .. 
communications cannot be established using ees 
means. . : 


Type 1 — A type 1 command is used to synchro- 

nize the master and the slave. It will cause the 

message counters (see subsequent paragraphs) to ~ 
reset to zero. This command i iS issued only by the’ 
' Master node. 


_ Type 2 — The type 2 message is defined to be that 

' which contains information which is to be moved 
between nodes of the communications network. 

_ The exact format of the data is discussed else- 

where. This is the only message which is not con- 
= sidered to be of a strictly handshaking nature. _ 


Type 3 —A type 3 message is used to indicate that 
a network node is responsive and ready to handle - 
messages. When’ normal communications have © 
- been established and no data messages are being 

sent, this message is continuously being sent be- 
tween the master and the slaves. 


Type 5 — The final message type is the type 5. It is 
used by the slave to respond to the master’s re- 
quest to synchronize. The receipt of this message 
indicates that the slave has performed all — 
necessary operations with its message counters 
and i is ready to receive messages. 


The next field is used to describe the number of mes- 
sages which contain data and have been received or sent 
by each node. The first character is used to indicate the 
number of messages which have been received from the 


master node to that slave. The second character indi- | 


cates the number of messages which have been sent 
from the master to the node. Internal software protocol 
enables the communications package to use these fields 
to determine if a data message has been received cor- 
rectly by the target node. If a response message does not 
contain the correct counts, the message can be retrans- 
mitted. Since only one character is used for each count, 
the numbers are allowed to recycle each 15 messages. 


The data field contains information which i is to be sent 
to the receiving node. Its exact content is discussed later 
in the application note during the discussion Ok the 
iRMX 80 message extensions. Ag 


A checksum is included to guarantee the integrity of the 
transmitted message. This. field’ contains the. 8-bit 
modulo 256 sum of all transmitted ASCII characters, 
beginning with the line feed and continuing through the 
last character of the data field. It is used to compare a 
calculated checksum of received characters with that 
transmitted by the sending node. If these two numbers 
are in agreement, ‘the message is considered to be valid 
and can be used by the receiving node’ s application soft- 


ware. 


The final field is the end of message character. A car- 
riage return is used and provides a unique indicator of 
the end of a message packet. 


The implementation of these communication concepts 
into a functioning software package is illustrated later 
during the discussion of the layering of the multipro- 
cessing communications Dackaee, 


Multitasking Message Concepts 


The design of systems which involve distributed pro- 
cessors strongly suggests that a multitasking environ- 
ment is also present. The ability to segregate an applica- 
tion into tasks allows a considerable simplification of 
the design and implementation process. In reality, few 
tasks represent completely. isolated functions.. Some 
degree of communications is required between the tasks. 


This may range from a simple synchronization of tasks 


to a data transfer. Real-time executives simplify these 
processes for the system designer. Intel’s iRMX 80 
nucleus is an excellent example of such an executive. It 
provides low overhead, small physical size, and operates 


on almost all 8-bit Intel single board computers. The 
product has been thoroughly covered in several applica- 


tion notes and it is therefore not necessary to cover it 
again in this note. However, certain features are useful 
for developing a distributed processor extension of the 
basic nucleus. 


An iRMX 80 message is analogous to a letter which is 


_ mailed to someone. It is sent via a mailroom or post of- 


fice (called an exchange) and is then picked up by the 
receiving party. Each part of the iRMX implementation 
can be thought of in this manner. When a serial com- 
munications link is used between the processors, the 


~ analogy translates to that of sending a mailgram. The 


following short discussion deals with the structure and 
mechanism for sending messages between tasks which 
reside on different single board computers. For clarity, 
the mail analogy is used. 


There are several distinct parts of a message. Each has a 
function and.a format within the message structure. 
Before a message can be generated, a medium must be 
procured to contain that message. In terms of a large 


_ office, this medium is paper; in the multitasking system, 


it is a block of RAM. In order to maintain a continuing 


_ supply of memory, the iRMX executive provides the 
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user with what is known as a free space manager. The 
purpose of the free space manager is to recycle memory 
blocks so that they can be again used for generation of 
additional messages. This service is called each time the 
sending task requires to generate a message. When the 
communication programs have successfully transmitted 
the message to the target node, the memory block is 
again returned to the free space memory pool. As the 
target node receives the message it must obtain a block 
of memory from its free space manager to store the in- 
formation until it can be processed by the target task. 
The target task returns the block to the pool when it has 
taken the appropriate actions. 


As with any type of message, the individual to whom the 
message is to be delivered must be provided. Because the 
iRMX 80 nucleus is designed to be used by multiple 
tasks on the same processor, the target address mechan- 
ism is not included in the message header itself; instead, 
the target is specified in the call to the iRMX procedure 
as a parameter list component. When the target ex- 
change address is not known, which happens when mul- 
tiprocessor applications are created, it is necessary to 
create an extension to the executive which allows the 
assignment of a target exchange name to each message. 
Fortunately, this is relatively easy to create. 


iRMX 80™ Named Exchange Extension 


The iRMX 80 nucleus uses a small block of RAM mem- 
ory to store data regarding the characteristics and status 
of each exchange. This storage area normally occupies 
10 bytes of memory. Its layout is shown in Figure 16. 
Except to note that a unique identification field does not 
exist which sets each exchange descriptor apart, it is 
beyond the scope of this application note to dwell on the 
meanings of the fields. However, a method must be cre- 
ated which allows the extension of the field to include an 
identification which is unique to that descriptor. 


| 


LENGTH 
c= am se en ann al 


EXCHANGE 
DESCRIPTOR 


(EXTENSION FOR 


MESSAGE 
INTERRUPT EXCHANGES) 


_ Figure 16. Exchange Descriptor 


If.one is not to rewrite the nucleus, the format of the ex- 
change descriptor must not be changed and the identifi- 
cation field should be added as additional. bytes. of the 
memory block. Two features of the iRMX 80 nucleus 
make the direct implementation of this concept impossi- 
ble. First, a special exchange descriptor already exists 


within the standard real-time executive. This is the inter- 
rupt exchange which adds 5 bytes to the nucleus for use 
as an interrupt message. Second, if an additional exten- 
sion were to be added, all exchanges would have to be 
created as interrupt exchanges so that common software 
could be used. While this would not in itself be prohibi- 
tive, the interactive configurator (ICU 80) does not 
allow addition of fields to either the standard or to the 
interrupt exchange descriptor. Another method is re- 
quired to add the extension. 


Fortunately, another method exists to create an ex- 
change. The nucleus operation, RQCXCH, creates an 
exchange at an address which is specified by a parameter 
of the call instruction. If user software is created to 
build the named exchanges, a name can be prefixed to 
each desired name exchange. 


In the standard iRMX 80 nucleus six characters are al- 
lowed to name each task. A logical extension of this 
concept provides a six-character name for each named 
exchange. The exchange descriptor is thus extended by 
inserting 6 bytes before the basic format. In realty, this 
is not sufficient because named exchanges are to be 
created dynamically. The memory blocks representing 
the set of named exchanges to not necessarily constitute 
a contiguous block of RAM. This leads to the creation 
of an additional word of memory to carry a pointer to 
the next named exchange field. A value of zero in this 
field indicates that no additional named exchanges exist. 
If a non-zero value is placed into the field, it is a pointer 
to the next named exchange. Figure 17 illustrates the 
structure of the named exchange fields. | 


FIRST$PTR 


ASCIINAME 


iRMX 80™ 
EXCHANGE 
DESCRIPTOR 


iRMX 80™ 
EXCHANGE 
DESCRIPTOR 


FIRST NAMED EXCHANGE LAST NAMED EXCHANGE 


Figure 17. Named Exchange Descriptors | 


The creation of the software to support the named ex- 
change extension is rather straightforward. Two func- 
tions are required; one which creates the named ex- 
changes, and a second which will return the address of 
an exchange which matches a given name. A complete 
listing of the software generated to perform these func- 
tions is shown in Appendix A. The services of the free 
space manager are used to allocate the memory ‘seg- 
ments which are used for the exchange descriptors. A 
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quick examination of the program techniques provides 
some insight into the operations involved ‘i in oe 
extensions to the standard nucleus. : 


Examination of the listing at line 55 shows that a proce- 
dure is used to allow user code to determine the absolute 
address of the iRMX exchange descriptor field from the 
named exchange lists. This address can in turn be used 
with either the RQWAIT or the RQSEND instruction in 
the user’s code. If no corresponding name is found i in 
the table, a value of zero is returned by the procedure. 
An address parameter is passed in the user call to the 
FIND$EXCH subroutine which points to the 6 bytes 
containing the ASCII name of the referenced exchange. 


An internal address value, identified as FIRST$PTR, 
contains the address of the first named exchange de- 
scriptor. A simple DO loop sequence is used to locate a 
matching name in the table lists. Either.a zero or the 
location of an actual '10-byte exchange descriptor 
the extended memory block is returned. oe 


A task i is used to provide the system capability of build- 
ing namied exchanges. A task, rather than a procedure, 
is included because a task allows the initialization of 
system pointers such as FIRST$PTR. The named ex- 
change building task, CREATE$COM, waits at its 
input exchange, COMS$CREATES$EXCH until a request 
for creation of a named exchange is received from a user 
task. The listing for this task 1 is found i in Appendix A, 
beginning on line. B. | 


When a message is received, the task ébtains a 20- vis 
block of memory from. the free space manager. It then 
moves the ASCII name from the requesting message 
‘into the appropriate fields and uses the iRMX primitive 
call, RQCXCH, to create an exchange descriptor within 
the memory block. The pointer field of the last named 
exchange is updated to point to the new memory field 
and the pointer field of the newly created named ex- 
change is set to zero. os 2 

Finally, the address of the actual exchange aescanton is 
returned to: the requesting program | as an updated 
parameter of the request message. ! 


The creation of named exchanges greatly enhances the 
capabilities of systems designed around the iRMX 80 
nucleus. This extension allows the generation of distrib- 
-uted systems in which tasks may communicate with each 
other’ regardless of their geographical locations so long 
as some type of link exists. 


Generation of Multiprocessing Serial 
Communications Link © 


The. creation of software for a aa conialinications 
link provides the capability of allowing: true multitask- 
ing, multiprocessor capabilities. The need: for two types 
of communications packages, a slave and:a master, indi- 
cates that two separate tasks are required. A’ compre- 
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hensive examination of the communication require- 
ments indicates that the system can be generated in three 
layers. Figure 18 shows the layer’ relationships. -The first 
is defined as the: protocol and consists of that code 
which is required to implement the algorithms for either 
the slave or the master network nodes. The second level 
is known as the link level and contains that code which 
is used to support common operations such as message 
generation and data queue handling. The third provides 
a specialized interface to the physical hardware which is 
being used to generate the communications link. This 
level, called the physical lees is sunt to a con- 
figuration. 


.. [| PROTOCOLLAYER |. 


rae LEVEL omen 


NEXT GIVE | TAKE TEST 


GENERATE READY 
NEXT TAKE| INITIALIZE eee MESSAGE OUT |GENERATE MESSAGE 


PHYSICAL LAYER 


INITIALIZE . | GET CHARACTER | SEND CHARACTER [staat SEND 


“Figure 1 18: 
PROTOCOL LEVEL COMMUNICATIONS 
PACKAGE |. > 


Two protocol level communications packages are in- 
cluded in this application note. One implements the 
master protocol and is reproduced i in Appendix B. The 
second, the’ slave protocol, is found i in Appendix C. 


No attempt is made to detail the operations which are 


‘involved in the task generation. The code is commented — 


and is readily followed by the reader who has an under- 
standing of PL/M programming techniques.” Some 
facits relating to the implementation of the packages as 
iRMX 80 tasks are in order. | 


The master communications package is desipnea to use 
a USART device which is configured to provide inter- 


_rupts at level’7 each time a character is received. A phys- 


-ical level interrupt handler supports the receipt of each 
individual character, and, when an end of message char- 
acter (carriage. return). is received, places an interrupt 
message into the interrupt exchange, RQL7EX. At this 
point (Appendix ‘B, line 244), the master protocol han- 
dler can begin processing the received message. Because 
the task is associated with interrupt level 7, a task prior- 
ity inthe range between 113 and 128 must be assigned to: 
the task. The example used in sou ee note uses 
a priority of 113.. 25% 
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In a similar manner, the slave communications task uses 
interrupt level 6 to receive messages (Appendix C, line 
130). Its priority must lie in the range between 97 and 
112. 


LINK LEVEL COMMUNICATIONS PACKAGE 


The link level communications package provides a com- 
mon set of procedures which can be used to support 
both the protocol and the physical layers. Listings of 
these support programs are found in Appendix D. The 
programs which make up the package are defined in the 
following discussion. 


Several procedures support the maintenance of the data 
queues. These are CQ$Q$INIT, CQ$NEXT$TAKE, 
and CQ$NEXTS$GIVE. The first, CQSQSINIT, is used 
to clear space for a data queue. It sets up the length 
parameter and the give and take pointers to their initial 
values. 


Data is placed onto the queue by calling the procedure, 
CQ$NEXTS$GIVE, and including the desired data in the 
paramter list. Conversely, CQONEXTSTAKE is used to 
take data from the queue. Both maintain the queue 
pointers as data is inserted or removed. For further in- 
formation about data queues, the reader should refer to 


AP-52, Using the iSBC 544™ Intelligent Communica- 


tions Controller. This document contains an extensive 
discussion on the subject of data queues. 


Two procedures deal with the transformation of data 
between printable ASCII and the internal binary for- 
mat. CQ$ASC$HEX transfers data from the data queue 
into a working buffer. In the process, it converts the 
format from ASCII into a hex representation usable by 
the target task. Likewise, CQSHEX$ASC is used to 
transform data in a user buffer into a transmittable for- 


mat. In both cases, appropriate start and stop charac- — 


ters are added or deleted as necessary to create the cor- 
rect format. 


One procedure deals with computing the checksum of a 
message which is in ASCII format. This procedure, 
CQ$CHECKSUM, returns a zero if the checksum 
agrees with that in the message. If an error is indicated, 
a value of —1 (OFF hex) is returned. : 


Finally, two procedures support the generation of mes- 
sage packets. One, CQSGEN$RDY, is used to build a 
‘‘ready’’ message by creating the appropriate data into 
the fields. The second, CQ$GENS$MSG, generates a 


data message containing an iRMX 80 message to be sent 


to an exchange on another processor board. 


PHYSICAL LEVEL COMMUNICATIONS PACKAGE 


The physical level communications package provides 
the customization for the unique configuration of host 


processor and USART. Four procedures must be in- 
cluded with this level. These are: 


e CQSINIT — This public procedure contains all 
operations necessary to initialize the timers, counters 
and USARTs associated with the communications 
code. In addition, this procedure defines the inter- 
rupt service routines for the USART and enables the 
corresponding interrupt levels. 


e CQ$START$MSG — A public procedure which 
places the USART into a mode in which the transmit- 
ter is enabled. The execution of this procedure should 
result in an interrupt being generated by the USART 
transmitter ready line. : 


¢ CQMIVT — This is an interrupt service routine asso- 
ciated with the USART receiver ready line. It is en- 
tered each time that a character has been received by 
the communication node. In the case of a slave node, 
this procedure is known as CQSIVT. The name is 
unimportant because the location of the routine is 
passed to the iRMX 80 nucleus at initialization by the 
CQ$INIT program. When a carriage return (end of 
message) is encountered, a message is passed to the 
protocol level task by passing a message to the inter- 
rupt exchange, RQL6EX, using the iRMX primitive, 
RQISND. | | — 


e SEND$CHAR — Like the CQMIT routine, this is 
an interrupt handler procedure. It is entered each 
time the USART signals that it is ready to transmit a 
character. A new character is obtained from the data 
queue and it is transmitted to the receiving node. If 
the character is the end of message, flags are set and 
the USART transmitter is disabled. 


The listing of a sample physical driver is provided in Ap- 
pendix E. This driver illustrates the use of the iSBX 351 
Serial MULTIMODULE Board placed into a socket of 
an iSBC 80/24 Single Board Computer. 


The example from the application implements a multi- 
drop slave node. The enabling of the tri-state drivers is 
accomplished in line 138 by sending the USART a com- 
mand of 025H. When the message has been sent, the 
driver is again placed into a high impedance mode by 
sending a command of 026H (line 121). These com- 
mands control the driver by toggling the DTR or Data 
Terminal Ready lines of the 8251A USART device. 


APPLICATION EXAMPLE 


- The alarm and security system previously discussed pro- 


vides a perfect environment in which to use the concepts 
developed in this application note. 


To verify the functionality of the communications pack- 
age, the transmissions between a master and a slave 
were monitored using a CRT terminal. The terminal was 
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connected to one of the RS232 serial paths using a tee 


network. This tee network is. shown i in Figure 19. ‘Sev- 
eral scenarios were set up to test the effectiveness of the 
communications protocol. The results of some of these 


tests are- recorded i in the following discussion. 


A test of normal communications. ‘was performed. in 
which one message. is. passed between the master and the 
slave. A short time later, a message is passed to the 


master from the slave. The CRT display for this action 


displayed as: 


. (line 1) 0330000 __ 
.. (line 2) 00300FD | 
(line 3) 03200091230900BF000000009F 
(line 4) 00310FE 
(line 5): 0331001 
(line 6) 002108247090087000000008A._ 
(line 7) 0331102 — - 
(line 8) 00311FF 


Line 1 As. a “‘ready”’ (character 3) message from the 
master node to a slave addressed. 03. hex (characters 1 
and 2). No messages have been sent in either direction at 
the time this message was. generated. On line 2, the slave 
has responded indicating that it is present. and ready to 
receive messages. It also has not transmitted any mes- 
sages to the master nor has it received any. 


The master node sends. the slave.a message on 1 line 3; 
Note that the message count field (aes 4 and 5)i 1S 


os 
= 
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not. changed until. after the message has. been trans- 
mitted. The message sent.is a type BF and has a. total 
length of 9. bytes. On line.4, the slave acknowledges that 
is has received one message and has sent none. 


Lines 5, 6, and 7 illustrate a sequence in which the slave 
sends a message to the master node. Prior to the mes-. 
sage being sent, the message count field shows that one 
message has been received. ‘After réceiving the message, 
the master node increments its received counter. . 


Tests with the alarm and ‘security system verify that the 
communication module functions correctly. Data integ- 
rity is maintained even through intentional disruption of 
the electrical link. Both the RS232 and RS422 communi- 
cation paths function as designed. | 


A’ detailed discussion of this ‘application ‘and of the 
multitasking capabilities of the iRMX 80 nucleus can be 
found in AP-112, Simplifying Complex Designs ane 
The iRMX 80™ Executive. 


CONCLUSIONS . 

This application note illustrates the ease with which a: 
user can add extensions to the iRMX 80’ executive to 
support a distributed multiprocessing application. ‘In 
addition, the ‘user of standard ' “off the: shelf?’ single’ 
board computers and expansion modules to create a 
hardware solution i iS explained. 


INES 
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y 
REMOTE © 


REMOTE 
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Figure 19. Communications Tee Schematic 
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The ability to break applications into small tasks, either 
functionally or geographically, aids the system designer 
by allowing his concentration on each task. A message 
transfer capability allows these tasks to again be tied 
together to form a complete solution to the application. 
Where the tasks reside on the same single board com- 
puter, the standard iRMX nucleus provides this ability. 
When different host boards are used, extensions to the 
nucleus allow the same functions to be performed. Both 
multiple processors on the same MULTIBUS chassis 
(refer to AP-88 and AP-112) and in different chassis 
using the serial links described in this application note 
can be supported with extensions to the nucleus. 


Many concepts are used to create serial communication 
networks. Intel’s single board computer products 
simplify the design process. Among these products, 
several stand out in this application. For example: 


e iRMX 80™ Executive — This outstanding product 
simplifies the design of multitasking systems and pro- 
vides a foundation for the implementation of exten- 
sions to create many varied configurations. Such 
things as task synchronization, interrupt handling, 
and message transfers allow multitasking. The free 
space manager allocates RAM and is an integral part 
of the serial communicaitons link software. The ter- 
minal handler and the disk operating system simplify 
the software design by providing ready to use I/O 
drives which can be accessed by thé user. 


iSBC 80/10B™ Single Board Computer — This 
microcomputer allows a low cost solution to many 
small to medium applications. The ability to operate 
the board in an iRMX 80 environment enhances its 
capabilities by allowing it to multiprocess. Its on- 
board serial communications link allows it to be used 
as a Slave node in either EIA or current loop com- 
munications networks. The iSBX MULTIMODULE 
connector further enhances its capabilities by allow- 
ing customization of I/O to meet a wide variety of 
user applications. 
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e iSBC 544™ Intelligent Communications Board 
— The use of this board allows much of the protocol 
and physical drivers to be off-loaded from the host 
processor. The board provides an ideal master com- 
municatons node for star type networks. By placing 
the handshaking operations on the communication 
board, the host is free to perform application- 
oriented functions with a much higher throughput 
rate. 


iSBC 80/24™ Single Board Computer — This 
powerful 8085A-2 based microcomputer board pro- 
vides the capability to implement most of the system 
functions without the need to expand to additional 
memory or I/O expansion MULTIBUS boards. It 
fully supports the iRMX 80 executive. Its ability to 
act as a full bus master allows even greater flexibility 
through the implementation of MULTIBUS multi- 
processor solutions. The two iSBX MULTIMOD- 
ULE expansion connectors provide the user with 
considerable flexibility in the design of his system. 
The use of one of these sockets as a carrier for the 
serial communications MULTIMODULE board 
makes a multidrop serial communications link prac- 
tical. 


iSBX 351™ Serial MULTIMODULE Board — The 
implementation of multidrop communications re- 
- quires the use of an electrical interface which sup- 
- ports more than one communicaitons node to share 
the link.-The use of the RS422 operating mode of the 
- board easily implements this feature. A well-defined 
hardware protocol also assists in the implementation 
“ of a serial multidrop communications link. Up to 11 
slave nodes can be designed into a system using this 
powerful board. In addition, the iSBX 351 board can 
function in either the RS232C or the EIA mode for 
linking into terminals or for creating a point to point 
network. 


The assistance of Judy McMillan in the implementation 


and testing of the security system and its communica- 
tion links is greatly appreciated. 
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APPENDIX A 


Stitle('RMX/&G0 EXTENSION TO NAME EXCHANGES, VERSION 1.3') 


createScomSexch: 

do; 
IIIT IOS IOI SII ISI III TI ICIS III III IO 
CREATSEXCHANGE creates a list of exchanges associating 
the name of an exchange. with its location, for the purpose 
of other tasks wishing to find the location of an exchange. 
FINDSEXCHANGE, when given the name of an exchange, polls 
Gown the list and, when it fines a match, returns the 
address to the requesting task. 
J BERR EERE EEE ERE KE KEKE EERE EKER KEEK EEE EEK EKER EEEKKEKEKKE 


Snolist 
/* declare exchanges used by the task * / 


declare COMSCREATESEXCH exchangeSdescriptor public; 
declare CREATESEXCH exchangeSdescriptor public; 


/* avclare pointers and messagges used by the task */ 


declare firstSptr address; 
declare last$ptr address; 
declare msgSptr address; 
declare exch$ptr address; 
declare n byte; 


declare request based msgS$ptr structure( 
msgShdr, 
exchSname(6) byte); 


declare fs$req structure ( 
msg$hdr, 
msgSlength address); 


declare exch based exch$ptr Serue rune 


name (6) byte, 
exchange(1@) byte, 
link address); 


declare lastSexch based lastSptc structure ( 
name (6) byte, 
exchange(1@) byte, 
link address); 

declare response based msg$ptr structure ( 
msgShdr, 
exchange address ); 


NAMEX: ; 
Procedure(exptr) address Sibi es 
ceclare addr address; 
Ceclare exptr address; _ 
Geclare (ex based exptr) (6) byte; 


/* declare the returning message with the address */ 
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Geclare ret$msq hased addr structure(msoahdr, 
exchSedr adcress); - : 


Pee ane eS SeS eho send to create @ named exchenge */ 


Hee ieee: req. structure (msgehdr, 
name oe DYEENs 


pk create an exche nde to Soninunexee wiek 


the comm creete exchange */ 


declare fsx exchangqedescriptor; 
call POCKeI fsx); 


/* build and send the Pequest message * / 


reaq.length = 1]5;. 

cell move(6, .ex, .req.name); 
req.type = 28; _ 
req.responseSexchange = .fsx; 

call rasend(.comcreates ‘exch, rea); 
addr rqweit(.fsx, #); | 
addr = retSmsgq. exchfadr; 


/* return with the address of the exchange */ 


return(acé@r); 
end; 


FINDSEXCH: 
procecure (nameSptr) aderess public; 


[RES Fe. KEKE KKEEKKKEEKEEKKKKEHEKKKEKKEKEEKKEEEKKEKEKAREKKKKKRKKEK 


This; trocecure finds the exchange having e name specified 
by the pessed parameter pointer. If a match is founce the 
exchange eddress is returnec. If no match is found, @ 


zero is returned, 
IORI OIG III ISI GIGI SIGIR II I IIRC 


declare nemefptr address; 
Ceclare metch byte; 
Ceclare (name based panes pent): Byte 


/* test for no exchenges */ 
if firstSptr = f. 
then return ff; 


/* test for a neme match */ 
else co; 
exchSptr = Pivse oper: 
Co while 1; 
match = @ffh; 
Co. n= © to S> 
if name(n) <> exch.name(n)- 
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then metch = 9; 


end; 
if metch then return .exch.exchenge; 
if exch.link = f then return (; 
exchSptr = exch.link; 
end; 
enc; 
return ©; 


end; 


CREATESCOM: 
procecure public; 


[RRR RKKREREKEKKEE RK ERE ERR EKER ERERER EKER REE KKRKEKKEKEEKKKKEKEE 


This procecure creates exchange extensions when asked to 
Go so by a task that wants its exchange meade completely 
eccessible. It saves the name of the exchanae tken 
creates an exchange to save its address. It may he updated 


at eny time. | | 
KHKEKKKKEKE KEKE KE KEK EERE RE RE KEK EERE KEK EKEKERERREKKEEKKEREEEEEE / 


/* initialize exchanges */ 
cell racxch(.comScreateSexch) ; 
call racxch(.createS$exch) ; 


/* initialize pointers */ 
lastS$ptr = @; 
firstSptr = 0; 


do while l; 


/* get a request for creation of an exchenge */ 
msqSptr = rawait(.comScreateSexch, €); 


/* get some memory for the exchange */ 
fsSrea.length = 11; 

FsSrea.type = 5; 
fsSreq.responseSexchange = .createSexch; 
FsSrea.msgflenath = 2°; 

cell rosend(.rqfsax, .fs$rea); 

exchSptr = rawait(.createfexch, ); 
exchSptr = fsSreaq.msgSlength; 


/* store name in the exchange structure */ 
call move( §, .request.exchfneme(—), 
-exch.name(f)); 


/* create en exchange */ 
call racxch(.exch.exchanae(f)); 


/* update the link field */ 
if lestSptr > @ 


then co; | 
lastS$exch.link = exchfptr; 
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C7 A lastSptr = exchSptr; 
OF a exch. Jink = 3 

SBS: 4 end; |: i 

Lee 2 else co; | 

1¢] 4 exch.link = ; - 

ba ier, A first$ptr = exchSptr; 
1¢3 4 last$ptr = exchSptr; 
1(4 4 enc; 

/* return the exchange pointer */ 
es = response.exchange = .exch.exchanae; 
1G6 3 call rasend(reauest.responseSexchange, msafptr); 
IG? #3 end; 

168 2° end; 
1Q9 ] end; 


MODULE INFORMATICN: : » 
GC1D2H 467D 


CODE AREA SIZE = 
VARIABLE AREA SIZE = (C4°H 72D 
MAXIMUM STACK SIZE = 


CAC4H 40 
244 LINES READ | my 
— PRCGRAM ERROR (S) 
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Stitle('Master Communications Protoco! -[river, Version ©.1]') 
i MASTEREDRIVER: co; 
/* 
The tesk containec in this listing supports the mester 
compmunicaetions protocol for extabJishing network commun- 
icetions. 


m 


The task must he confiaured usina the ICU/PC es follows: 
TASK NAME: MASTER 

TASK ENTRY POINT: MLINE 

TASK PRIORITY: 112 

TASK STACK LENCTH: 1¢¢F 


EXCHANGE: PROL7FX 
SCOPR: FXTERNAL 
INTERRUPT? YES 
EXCRANGE: TIMEX 
SCOPE: PUBLIC 
INTERRUPT: NOC 


LINK: :Fn:COMSTR. CBJ 


LINK: :Fn:COCCM,LIB 
LINK: :Fn:CCRSELV.LIB 


Tasks desiring to send a message to a node should 
sena @ message to the exchanae COMIEX (node). 


Certain incluce files ere used by the tesk. 
itd 
Sin -lude (:ff:exch.elt) 
CEC" °T ER EXCPANGESPESCRIPTOR LITERALLY 'STRUCTURF ( 
MEGSHFAD ADDRESS, 
MSGSTAIL ADDRESS, 
TASKSHEAP ADDRESS, 
TAEKSTAIL ADDRESS, 
NEXTSEXCH ALDRESS)'; 
Sinclude (:ff:ied.elt) 
DECLARE INTSEXCHANGFSDFSCRIPTCR LITERALLY ‘STRUCTURE ( 
MESSAGESHEALr ADDRESS, 
MESSACESTAIL ADDRESS, 
TASKSHEAD ADDRESS, 
TASKSTATL ADPRESS, 
EXCHANGESLINK ADDRESS, 
LINK ADPRFCC, 
LENGTH ALDRESS, 
TYPE PYTE)'; 
Sinclude (:fC:msa.elt) 
DECLARF MSGSHDR LITFRALLY ' 


NO 
—) 
It 


ta) 
—_ 


a> 
a) 
W 
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LINK ADDRESS, . 

LENGTH ADDRESS, 

TYPE BYTE, 

HOMESEXCHANGE ADDRESS, 
RESPONSESEXCHANGE ADDRESS'>.. 


DECLARE MSGSDESCRIPTOR eee "STRUCTURE ( 
MSGSHDR, © | eae = Ls. 2 _ 
REMAINDER (1) ae 
Sinclude (:f@:common.elt) 
DECLARE TRUE LITERALLY '‘'@FFH'; 
DECLARE FALSE LITERALLY '@6H'; 
DECLARE BOOLEAN LITERALLY 'BYTE'; 
DECLARE FOREVER LITERALLY 'WHILE 1'; 
Sinclude (:f@:synch.ext) 
ROSEND: 
PROCEDURE (ExCHANGESDOINTER: MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTER,MESSAGESPOINTER) ADDRESS; 


END RQSEND; 
ROWAIT: 
PROCEDURE (EXCHANGESPOINTER, DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGESPOINTER,DELAY) ADDRESS; 
END RQWAIT; 
RQACPT: 
PROCEDURE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 
cassia EXCHANGE Y POINTER’ ADDRESS; 


END ROACPT; 


~ ROISND: 


PROCEDURE (IEDSPTR) EXTERNAL; 
DECLARE IEDSPTR ADDRESS; — 


END RQISND; 
Sinclusue (:f@:intrpt.ext) 
RQOENDI: 

PROCEDURE EXTERNAL; 


END RQENDI; 
RQELVL: : 
PROCEDURE (LEVEL) EXTERNAL; — 
DECLARE LEVEL BYTE; 
END RQELVL; 
RODLVL: | 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; | 


END RQDLVL; 
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ROSETV: 
PROCEDURF : (PRCC,LEVEL) FXTERNAL; 
CECLARE PROC ADPRESS; 
DECLARE LEVEL BYTE; 


FND ROSFTV; 


ROSETP: | | 
PRCCEDURFE (PRCC,LEVEL) EXTERNAL; 
DECLARE PRCC ADDRFSS; 
DECLARE LEVEL BYTE; 


END ROSETP; 
Sincluce (:ff:fsmaqr.ext) 


DECLARE ROFSAX EXCHANGFSDESCRIPTOCR: EXTERNAL; 
DECLARE ROFERX EXCHANGESDESCRIPTOR EXTERNAL; 
DECLARE RQFREE EXCHANGESDESCRIPTOR EXTERNAL; 


Sincluce (:fl:masmsq.elt) 


Geclere msg$formet | literally ‘structure ( 


trot byte, 
cmnd byte,> 
segSle byte, 
seq$ne byte, 


text (25) byte )'; 


declare queve$ format literally "structure 


end§ptr byte, 
givefptr - byte,» 
takeSptr byte, — 


GaetaSbyte(254) byte )';. 


Geclare parSformet literally ‘structure 


ne byte, 
la. byte, 
run | -_ byte, 
SOD byte, 


quesSpt byte )'; 
Sinclude (:ff: objmen. ext) 
ROCTSKs 
PRCCEDUBE . (STATICSPTR) EXTERNAL; - 
DECLARE STATICSPTR |. PEERS 


END ROCTSK; 


ROCXCH: ! 4 ! bis 4 
PRCCEDURE (EXCHANGESPTR) EXTERNAL; 
DECLARE EXCHANGCESPTR ADDRESS; 


END ROQCXCH; -- 
Sinclude (:fl:comcom.ext) 
COSNEXTSGIVE: 
Procedure. (a$ptr,qivefbyte) - byte 
Declare qfptr. address;. 
Declare qiveSbyte byte; 
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end cgqSnext$qive; 
COSTAKESTEST: 
| Procedure (qfptr) hyte externa ts 
Declare cfptr adcress; 
end caftakeStest; 
COSNEXTSTAKE: 
Procedure (a$ptr) byte externel; 
Declare qS$ptr address; 
end cafSnextStake; 
COSCSINIT: i -_ 
Procedure (a$ ‘ptr, qgsize) external; 
Neclare q$ptr address; | 
Declare qfsize hyte; 
enc cqfqSinit; 
COSASCSHEX: 
Procedure (asptr, msq: ptr) eee 
Declare (qf ptr,msgSptr) address 
-. end ecqSescShex; i 
AOE CUECK EU. 
Procedure (qfptr) yee external; 
Peclare afptr address; 
enc cofchecksum;. 
COSHEXSASC: 
Procecure (qfptr,hrex$ Gee, external; 
Peclare qfptr acdress; 
RecjJare hexSbyte BYES: 
end caSbexSasc; 
COSMSGSOUT: ; 
Procecure. (msgSsize, afptr,persptr, msas Sptr) external; 
Declare msgfsize byte; 
Res cies (q$ptr,parsptr,msasptr) address; 
enc caoSmsgfout; 
COSGENSRDY: a3 
Procedure (trget, msas éptr, afptr, part ptr) external; 
Declare Lege’ UES: 
Declare (msofptr,q$ a ptr) adcress;. 
end caSgenSrdy; 
COSCENSMSCG: 
Procecure (msq$ epi neers: beget, msgfptr,qSptr, 
perSptr,saevetfia) external; | 
Declare (traet,savefSflg) eed 
Declare (nsgfpointer, msgf€ptr,qSptr,parSptr) address; 
end ca$gqens$msg; 


USRINT: 
Procedure external; 
end usrint; 

FINDSEXCH:  . | 
Procedure (namef Bory address exberned: 
Ceclare namefptr address : 
end findSexch; . 

NAMEX: 
Procecure(exptr) address: external; 
declare exptr. aCOreSsi | 
end neamex; . : es 


2-196 | AFN-01931A 


intel APPENDIX B 


O4 ] returnf ram: , 
procedure(pointer) external; 
os 2 declare pointer address; 
oF 2 end returnf ram; 
/* 


Certain literals are used to define the network's 
physicel charecteristics. These ere: 
* / | 
O7 1 Declare NSNCDE literally '4'; /* number of noces */ 
OF ] Reclare NCDFSARRAY literally ‘'5'; 7 


/* 
A structure provides the Cate queues for the 
transmission of data to eack node. It is cefined 
and is available as a public 


if: 


Ve) 
iY) 
— 


Declare COMSTO aueueSformat public et (&1lick); 
/* 


A single date queve is used to support. the input of 
deta from a node since only one slave is given a 
window at a time: 

alt 4 
10¢ ] Neclare CQOMSIQ queueSformat public at (R&f1bh); 


f= a 
Each node has an assSocieted set of flags which 
incicate the operational mode of that node. The 
function of each bit is defined as: | 
bit - request synchronization (synchf request) 
bit - request initialization (initSrequest) 
bit - repeet last messeqe (repeatfreouest) 
bit - 
bit 
bit 
bit 
bit 


Nu S ty Pe NR 


- error fleg (error$flaq) 


~ 


a 
11 
162 
Le3 
1@4 
1¢5 


Declere COCMDF(nodefarray) byte public; 
Declare SYNCHSREQUEST literally '1H'; 
Ceclare INITSREQUEST literally 'f2H'; 
Declere REPEATSREQUEST literally 'f4k'; 
Declare ERRORSFLAG literally 'e@CH'; 


og ee 


/* 
A counter is used to indicate the number of attempts 
to establish communications with @ node. When it 
reaches @ maximum value, e@e synch will ke sent to the 
node. when the maximum value of synchs are sent to a 
node with no effect, eae reset will be sent to the node. 


*/ 
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Declare ERRORSCOUNT (noceferray) byte; 
Ceclere MAXSCCUNT literelly 'S'; 
Teclere SYNCHSCOUNT (nacefarray) byte; 


/* a pointer is used to store the ecdress of exchenges 
usec byincomming messeges*/ 


Declare targetfexch address; 


ee 


/* 

A set of exchanges is used to hole@ a messeae until it 
has been ecknowledaed by the slave. | | 
Declare HOLDSEXCEH (nodeSarrey) exchangeSdcescriptor; 

f° | oe 
~B set of exchanges is provided to accept messages which 
are to be sent to any of the nodes. 
a 
Declare COMIEX(noceSarray) exchangeScescriptor public; 
The task uses verious sets of data structures 
a/ > ie | 
Teclare req$msa structure ( 
—msagShdr, — 
meqSlength address ); 
Declare (m,n,nodefcnt,outmode,ramSsize) byte; 
Declare msg$ptr address; 
Declare msq msg$format; 
Geclare start°f544 byte public et (&PCh) : 
Declare data$block based msgfptr structure ( 
| msgfhedr) ; 
Peclare COMPAR (nodes erray) parSformet public 
at (&N€2h) ; 
Declare RAMSMSG based msgfptr structure ( 
msgShdr); 
Declare CQSACTIVESNODE byte Subiie et (@CAlh); 
Teclare frefmem acdress; 
Declare fre$msq based frefmem structure(msaStear) ; 
/* 
The task uses certain exchanges | for. internal 
communicetions 
i 


Declare coms SEX exchéngefdcescriptor; | 
Declare ROL7EX intSexchangeScescriptor public; 
Seject 
[ RRR RRKRIEK RE KIERERE RK KEIRI RK ERKE KEE KE KEKE EEE KE KEREREEKREEE 


errorStest 


This short procedure is used to increment the error 


counters and to signal an initialization or synch command 
when required. Tt will order a re-transmission of the 
last.message each time an error is detectec. 


KEKKKEKKKKKEKEKKEKEKEKEKREKRKEKEEKE EEK KEKEEEKEKKKEKEEKKERKEEKEKEEKSE / 
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125 ] errorstest: procedure; 
126 2 Tf (errorScount(n) :=errorScount(n) +1) > maxScount 
then do; 
12€ 3 errorScount(n) =; 
12°¢ 3 if (synchScount(m):=synchfcount(m)+]) > mexfEcount 
then co; | 
Led a synchfcount(m) = (; 
132 d cacmef(n) = cacméef(n) or errorftflag 
or initSrequest; 
132 a enc; 
134 3 | else cocmdf(n) =cqcemef (n) 
_or errorSfleo or synchS request; 
125 2 end; 
126 2 else cacmef(n) = cacmdf(n) or repeatSreauest; 
127 2 return; 
12& 2 e- * srrorstest; 
Seject 
AS ES. ] MLINK: Procedure public; 


/* Initialize the system enc the tesk */ 


14¢ 2 Do n=f to NSNODE; 
14] 3 COCMDF(n)=synchfSreaquest or errorcflaq; 
142 3 COMPAR (n).cun,CQMPAR(n) .stop,COMPAR (n) .queSpt=C; 
143 2 ERROCRSCOUNT (n) =9; 
144 3 SYNCHSCOUNT (n) =; 
2 


L465 end; 


/* Initialize the node pointer */ 
146 2 a NODESCNT=f'; 


/* Initialize the input exchanges */ 


147 2 Do N=f to nfnode; 
14€& 2 cell ROCXCH(.COMIEX(n)); 
y4°¢ 3 call ROCXCH(.HCLDSEXCH (n)); 
bigs & 2 end; 7 
151 2 call RCCXCH(.COMSEX); 
/* Initielize the cueues */ 
152 ? call caqfafinit(.caqmstq, 254); 
1:52 2 | cell cafaqSinit(.camsia, 254); 
/* Create the nemed exchanges enc aive ram to fsm*/ 
154 2 a cell usrint; 
y* initialize the level 7 interrupt exchanae */ 
155 2 | call rgqelvl(7); 
/* Begin main tesk loop */ 
5S 2 - Po forever; 
/* Begin support of one nodal channel */ 
157 3 | Do n=] to nfnoce; 
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Lae 


enc; 


/* reset eueue pointers ¥*/:" 


ees eaves oes canstq.te BRee pes = ¢; 


/* Compute qoeai moa number */ 

If (cocméf(n) end synch request) >F 
then outmode = lp is! 

else outmoce = (7. | 
If (cgemeéf(n) anc inits peGuueee 
then outmoce = ? 

cafactive$node = n; 


/* if comm féllure, kill ell messages */ 


“df (cacmef(n) and errorsfleg) > 6 


then do; | 
do while (msoSptri=raacpt(. camiex(n))) > C; 
call RGeU re ban psd: per) s 
enc; | 


Go while (msgSptr:=raaecpt(.fholdfexch(n))) 
> Fe. 
call return$ram(msg$ ptr); 
end; 


/* Operate on nodal mode * / 
Do case outmode; - 


/* case ©, routine communications */ 
Dog. | 
Tf (cacmdf (n) and Pobcer pages 
een Co; 


— SUPPOE. of retrensmission request */ 
oe not: repeats reavest; 
msafptr=raaecpt(.holdfexch(n)); 
if msgfptroe 


~/* retransmit old messege */ 
_then COR 
| at. camper (n) . ne=C 
then camper(n).ne = 15; 
else camper(n).ne=canmper(n).ne 
aca 
cell cafcenSmsa(msafptr,n,.msg, 
.caqmstq,.campar(n) ,(); 
call rqsend.(. holeSexch(n), 
 ‘msafptr); 
if campar(n). na = le 
then carper(n). = 
else cqmpar(n). ae 
" =compear(n).natl; 


eG 


end; | 


2-200 AFN-01931A 


bs ped ps be 
i919 19 un 
DS GN 


pes) 


CO 


APPENDIX B 


/* no oJd message, send ready */ 
else co; 

mnsq.trat=n; 

msa.cmnd=3; 

call caSmsgfSout(@,.cqmsta, 

.ecgmper(n),.msq) ; 
end; 
/* enc of retransmission */ 


/* support of next message */ 
else co; 


/* clear Fold exchanqe */ 
nsgfptr=rgqacpt (.holdSexch(n)); 
if msgfptr>e 

then Co; 


/* free space return size */ 

remsize=catafblock.length; 

if (ramsize mod 4) > fF 

then C@atefShlock. length 
=dataSblock.length 
+(4-(ram$size mod 4)); 

call ROSEND(.roafsrx,msqfptr); 

enc; 


/* test for @ message output */ 
msgfptr=rqaecpt(.camiex(n)); 


/* when a messade exists */ 
if msgSptroe 
then co; 
if (targetSexch: 
=fFindSexch(msgfptr +°))> F 
then call : 
| rqsend (targetfexch,msqs ptr) ; 
else co; | 
call ceafSaenfmsa(msgfptr,n,.msg, 
ecomstoa,.campar(n),f&); 
call rosend(.holcfexch(n), 
msafSptr); | 


/* increese tke na flaq */ 
if cqmper(n).na = 15 
then camper(n).ne = €; 
else campeaer(n).ne 

= compar(n).ne + 1; 


end; . 


-end> | 


/* when no messaeqe exists */ 
else do; 

msa.trqt=n; 

-msa.cmnd=3; 
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220 i Be ee ae a Eke call cafmsqfout(f,.camstea, 
| pager: = ane scomper(n),.msa); 
ee e | n. He end; 


204 7 eZ te ETNIES /* enc of routine messeqe */ 


a stert the messaade transmission * / 


225 6 ~startfS&44 = n; 
Peas 6 enc; /* enc of case f */ 
/* case.'1, synch request */ 
24 i) | Co; 
228 Go ae RS eg: —. camper(n).ne,campar(n). = (; 
229 4 & AS eg ms. trat=n; 
2o8 » _* msg.cmnd=]; 
| an | : cell cafmsgSout 
up ee eee ee Tr (€,.-camstq,.campar(n),.msaq); 
Zee et ep Fe eo re. gtarts544 = n; 
223 6 : i a cacndf(n)= cacmef (n) 
Se a ae anc not synchSreauest; 
234 4 end; 
/* case 2, initialize request */ 
235 5 | do; 
226 A ON oe oo 6Gaemef (n)=(cacmef(n) and 
_ not initSrequest) or synchfrequest; 
227 Ar 8 ae Be i > @ campar(n).na, campar(n).la = ; 
220 oR msg. trgt=n; 
ons 5 oo msg.cmnd=; 
246 6 . a ~ cell cafmsafout 
= 9 : nr ee a (C,.camstca,.caqampar(n),.msa); 
241 6 | Oe gtart$h44 = n; 
242 He a. OS a oo. ends 
243 5 ena; | /* ene of Co case blocks */ 
a . .. Sf* wait for a response from the slave */ 
244 A i -emsgSptr = rqwait(.rql7ex,25); 
245 4 7 Start$544 = 6%; 
A /*.test for a message or a timeout */ 
246 Ay Gai ‘— | if. remsmsg.type=< 
J support of no velidc response */ 
then 
/* test for max number of errors to noes */ 
247 4 call errorStest; -— 
: : /* support of gooc response return */ 
248 f | else do;)) 


—f* test for gooc checksum */ 
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then co; 


if cafchecksum(.cqmsiq) =0 


/* convert message to hex format */ 
call caSascfhex(.camsiq,.msa) ; 


/* test for Cata message receipt */ 
if msa.cmnd = 2 


/* support receipt of date messaqe */ 


then 


do; 


/* aet rem from free space manager */ | 
reafmsq.lenath=]1;. nS 
reaSmsg.type = 5; 
reacmsg.responseSexchanqe=.caSmsfex; 
reqSmsq.msqSlenqth=msq.text(?); 

céll rasend(.rafsax,.reas$msa); 
msaSptr=rawait (.cafSmsfSex,); 
msofptr=reaqtmsq.msaSlength; 


/* move messege into memory */ 
cell move(msa.text(2),.msa.text (f) 
mmsaqcptr); 


/* if taraet is another node... */ 

if msa.troat > fF 

then call rasend(.cqniex(msq.trgt) 
msgSptr); 


/* if target is master hoard */ 
if (targetSexch:= fineSexch(msafptr + 


> £ 

then 

cell rosene(taraetfexch, msgfptr); 
else do; 

rersize = msq.text(2); 

if (remsize moe 4) > Ff 

then msa.text(2)=msa.text(2) 

+ (4 -(ramsize mod 4)); 

call rasend(.rcfsrx, msafptr); 

enc; 


/* increment message counter */ 
if caqmper(n).le = 15 
then camper(n).la = ; 
else camper(n).le=campar(n) .latl; 


end; 


/* respone to non-secuence acknowledge */ 
if mso.cmna = 
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. then camfpar(n). 


er CGPS Dern): nea = £; 


/* test for a qood slave LA response */ 
dif campaer(n).ne = 


else co; : 
if msq.seqla <> camper(n).na 


end; 


fos 


end; 


else 


enc; 


enc; 


then cacmcf (n) 


msg.seqle + ] 


then call errorStest; 


= cacmef (n) 


or synchreaquest; 


eJse Co; 


errorfcount(n) = Ff; 


cacmecf (n) 


enc; 
end; 


= cacmcf (n) 


and not errorSflea; 


/* end of response return */ 
upport of hac checksum */ 


call errorStest; 


a end of messege arrived options */ 
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Stitle('Slave Communicetions Peckege Version 2.? 
COMSLVSMCPULE: 0; 


/* 


i 


This is the sJave communication main task. 
It should be configured into the system 
having the following parameters: 


Tesk name- CQOSLAV 

Task entry point- CCSLAV | 
Tesk priority- as required 
Task stack length- 16 


The LINK and LOCATE commancs of the user 
mi. t include the following statements: 


Link’ 
>:Fn:CQOSLAV.CBJI 
-Fn:COS251.0BI 
>:Fn:COCOM.LIB 
>Fn:CORSLV.LIP 


Several system parameters must be cefined 
in the user code to cefine the mode 
characteristics. These paremeters are cefined 
as: 
ca$slad- e byte value providing the 
nodal address of the commun= — 
ication node. | 
freSmem- an address value which provices 
a pointer to @ block of RAM to 
he assianed via the free spece 
maneger to the communications. 
ramflen- an address value which indicetes 
the size of the ehove block. 


declare casled byte external; 


Snolist 
Sinclude(:fl:commsg.elt) 


Ceclare msgSformet literally "structure ( 


trat byte, 
cmnd byte, 
seq$la hyte, 
seaSna byte, 


text (25%) byte. y's 


declare queuefSformat literally ‘structure c 


endfptr byte, 
giveSptr byte, 
tekeSptr byte, 
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CataSbyte(254) byte )'; 


Ceclare perfSformat literally ‘structure ( 


la byte, 
one 7 byte, 
run byte, 
stop byte, 


guefpt byte )'; 
Sinclude(:ff:objmen.ext) 
ROCTEK: | - 
PROCEDURE (STATICSPTR) EXTERNAL; 
DECLARE STATICSPTR ADIRESS; 


END ROCTSK; 


ROCXCH: 


PROCEDURE (EXCHANGESPTR) EXTERNAL; 
DECLARE EXCHANGESPTR ADDRESS; 


END ROCXCH; | 
Sinclude(:fl:comcom. ext) 
CQSNEXTSGIVE: 

Procecure (aSptr,giveSbyte) byte external; 
Reclare g$ptr address; 
Teclare giveSbyte byte; 
end cqSnextfaive;. 
COSTAKESTEST: 
Procedure (q$ptr) hyte external; 
eae aSptr adccress; 
uw eagStakeStest; 


| COSNEXTSTARE: 


Procedure (q$ptr) byte external; 
Declare afptr aderess; _ 
enc caSnextStake; 


~—COSOSINIT: 


Procedure (gfptr,q¢size) external; 
Declare qfptr edcress; 
Declere gq$size byte; 
end caSdSinit; 

COSASCSHEX: 
Procedure (q§$ ptr, msgqSptr) external; 
oe (q$ptr,msgSptr) address; | 
enc coSascfhex; 

GesenrcKeun: 

Procedure (q$ptr) byte externel; 
Declare aq$ptr address; 
end cqSchecksum; 
COSHEXSASC: 

Procecure (afptr,hexfbyte) external; 
Declere ofptr address; 
Declare hexfbyte byte; 
end caqShexSeasc; 

COSMSGSQUT: | 
Procedure (msgSsize,aSptr,parSptr,msgfptr) 
Declere msafsize byte; 
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(aSptr,perfSptr,msaSptr) address; 


cqSmsafSout; 


COSGENERDY: 


Procecure (traet,msgfptr,aSptr,parSptr) 


external; 


Declere trqet hyte; 


Declare (msq$ptr,qSptr,parf ptr) address; 
ene cafaenftrdy; 
COSGENSMSG: 


Procedure 


efflg) 


Declare 
Declere 


end 
Declare 
Peclere 
Declere 
Ceclar. 
Declere 


external; 

(trget,saveSflg) byte; 
(msqSpointer,msgqSptr,aSptr,perfptr) acdress? 
caSaenSmsq; 

ROLAFX intSexchangeScescriptor public; 

COSTEX exchangeSdescriptor public; 

cmraex exchangeScescrifptor; 

we ildaSsleveSex exchangefdescriptor public; 

catime exchangeSdescriptor public; 


cqSstartEmsas35): 
procedure external; 


end 


CGSINLES 


cqSstart$msg£351; 


S35]: 


procedure external; 


enc 


caSinits25J> 


fineSexch: 
procecure(nameSptr) address external; 
Geclere nameSptr address; 


end 


findSexch; 


cqfstartup: 
procedure external; 
enc cafstertup; 


ceclare 
Ceclare 
ceclare 
declere 
ceclere 
Ceclare 


Ceclare 


/* 
The 


cafinSsl queueS format public; 
eqSoutSsl queueSformat public; 
msg msgfformet; 

cafpars parSformat public; 
freSmem edcress; | 
cacmef(5) byte externel; 


FreSmsg based frefmem structure ( 
msaqSher ); 


message which is trensmittedc between nodes 


follows the description below: 


The 


STX 


complete message structure is Cefinedc as: 


TARGET COMMAND SEQ “TEXT CHECKSUM ~ECT 
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With the exception of the start of text (a line 
feed) ane the end of transmission (a carriage 
return), all cheracters transmitted in the message 
string will consist of printable ASCII characters. 


The target field consists of two frames which 
represent the hex ade@ress of the device to which 

the message is acdressec. The protocol allows for 
up to 256 unique device addresses. 


The command field indicates the type of message 
which is being sent in the network. It consists 
of a single frame representing e hex number in . 
the range from ( to (FH. The current message 
Gefinitions are: : ts 


commend lebel — 
0 INIT 
] SYNCH 
2 DATA 
2 READY 
4 NOT READY 
5 NON CEO ACK 
6 reservec 
we 
° ot 
: 1 
: ; 


This is the main link level RMX/®F communications 
task which supports slave operations of a single 

board computer. Several high level functions ere 

supported by” this task. | 


Messages conteining Cate mey be sent or received 

by this tesk. To send e message to another processor 
on the communications loop, a message of the formet 
shown is placed into the communications exchange, 
COSIEX. When the message has been transmitted, the 
RAM area in which the message was located will be 
returned to the free space maneger. 


Messages mey @lso be received by the boare when they 
are addressed to the communicetions address assianed 
to this board. When e message hes been received, it. 
will be transferred to a block of RAM obtained ron 
the free space manaqer and then sent to en exchange 
which is Cesignated in the name field of the 
messaqde.. | oe | 
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The formet for a Gata messege is: | 
msgSher targetexchangeneme message 


Deta may he up to 2?5¢€ bytes in length. 


A special commanc, INIT, can be receivec by the 


communicetions Criver task which will cause a 
softwere reset of the single board computer. 


CCSELAV: Procedure public; 


Geclare tergetfexch adcress; 


ceclere name eccress; 
Declare msqfptr eddress; 
Ceclare ramsize acdress; 


Declare RAMSmsg besec msgfptr structure ( 
msgSher );° 


Declere regfmsg structure ( 
msgSher, 
msgflenath edcress ); 
/* initialize the task at power up */ 
call cqfafSinit(.caSin§$s!], 25f); 
call cqSaqfSinit(.cqSoutfsl, 25); 
cafpers.run, cq$pars.stop, cqSpars.quespt = £; 


/* build required exchanges */ 
call rgqexch(.rql6ex); 

call racxch(.cqsiex); 

call racxch(.cmrqex); 

call racxch(.cotime); 

call cginit$351; 


co forever; 


/* wait for a wineow from the mester */ 


msgSptr = rawait (.ROLSEX, 4f—); 


/*test for good communications with iIM0OS*/ 

if ram$msg.type <> 3 then Co; 
/* test for the receipt of a velid message 
if ca$checksum(.caSinSsl1) = 6 


then do; 


/* convert the messaqe into hex format 
call cafascShex(.cqfin$sl],.msq); 


/* see if message is for this slave hoard */ 


if msa.trqt = casleéed 
then co; 
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name = .msg.text + 9; 
eageméef(?) = cacmeaf(f) and 7fh; 


/* pand@le each message type by case */ 


do case msq.cmnda; 


/* case f, INIT command */ 
‘céll cqstertup; 


/* cese 1, SYNCH commande */ 


Co; 


 f* reset counters */ | 
cafpars.Jléa,cafpars.na = 8; 


/* initeilize deta aqueues */ 

‘call caSqSinit (.cqfinSs!,25f%); 
call cqSqSinit (.caSoutfs],250); 
/* return non sea ack message *#/ 
msgq.trgt = (; | 

msg.cmne = 5; - 
call cqfmsgfout (f,.cqSoutfsl,.caqt 


, . call cgSstert$msa351; 

- end; : | | 

/* case 2, DATA command */ 
WOO god Se Le 


/* test for correct NA */ 
. . if eqpars.na = msg.seafna 
oo «then doz . 


/* clear old messaqes */ | 
msgfptr = raacpt(.holdf€slavefe 


if msqfptr > fi : 
tren call returnSreaem(msofptr); 


/* increment LA counter */ 
if (coSpars.la:=cqfpars.latl) 


then cafpars.LA = f; 

/*verify that exchange exists* 
~ TARGETSEXCH = FINDSEXCH (name); 

if TARGETSexch > 

then do; 


/* get RAM anc store messa 


Ae ee 


a3 


recfmsa.length 
reqSmsg.type = 
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= .cmSraSex; 


ext (2); 


q.text((), msg$ptr); 


msg¢ ptr); 


reafmsa.responseSexchange 


reaSmsa.msafSlength = msq.t 


call ROSEND (.rcfsax,.reas 


msgSptr RQWAIT (.cmfrale 


msgfptr reqSmsq.msoSleng 
cell move (msa.text(2),.ms 


call ROSENP (targetfexch, 


‘end; 


cqfoutSsl,.caSpears) ; 


h(msgptr + 9)) 


ch, msgfSptr); 


Cc, msg, cgqSoutSsl,.cqfpears,£); 


eSex, msaSptr); 


aa 


enc; 


tes 


/* test for cata out reauest * 
msaSptr = ROACPT (.cqsiex) ; 

if msqSptr = ¢ 

then call cafaqenSrcy (f,.msq,. 


else co; : 
if( targetSexch:= findSexc 


then call rasend(tergetSex 


else do; 
cell cagen$msa(msgptr, 


call rasenée(.holdSslav 
enc; 


enc; 


f bad ne, then retrensmit last 


else do; sara 
-capers.ne = msg.seqfna; 


msgfptr = raacpt(.hboldfslavefe 


if msqfptr > ¢ 
then do; 
call cafaenfmsa(msqfptr,f, 


.msa, cq$out$sl,.cq$pars,f); 


' msgfptr); 


enc; 
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/* send messege */ 
call cafstart$msg£351; 
enc; 


/* case 3, RDY command */ 
do; 


/* verify na is correct */ 
if cafpers.na = msg.seqSnea 
then co; 


/* clear ole messeqes */ 
msgSptr = raacpt(.holdeSslavefe 


if msq$ptr > £¢ 
then call returnSrem(msgf$ptr) ; 


/* test for a message waiting 
to be sent */ 
msg$ptr = ROACPT (.caqsiex); 
if msoSptr = f : 
then call cafgenfrdy (£,.msg,. 


else do; : 
if (targetSexch:=findSexch 


then call raqsend(tergetSex 


ch, msaSptr); 


else ¢o;- 
| cell coSqenSmsa fmsgS pt 
r,f, msg, caSoutfsl,.cafpars,£); "od 
| a. | cell rasene(.holdSslav 
efex,msgfptr) ; | s 
end; 
end; 


end; 


/* if bee na, then retransmit last 


a 
else do; 
capars.na = msg.seqfSna; 
msgfptr = rqacpt(.holdfSslaveSe 
x)i | | : 


if msgSptr > ¢ 
then co; 
| call caS$genfmsg(msaqfptr,f, 
omsg,.caSout$sl,.cafpars,£); | 
; call rqsend(.holdfslavefex 
, msqSptr); = 
end; 
enc; 


/* start trensmission */ 
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/* clear out messages if com failure exists */ 


else do; 


end; 


Go while 


enc; 


call 


enc; 


(msoSptr:=raecpt(.casiex)) > CF; 


caJl caSstartSmsgf25 


end; 


/* case 
do;end; 


/* cease 
do;end; 


/* case 
do;enc; 


/* case 
Co;end; 


/* case 
do;end; 


J/* case 
Go;end; 


/* case 
cCo;enc; 


/* cese 
Co;end; 


/* case 
do;end; 


/* case 
do;zend; 


/* case 
do;end; 


/* case 
Co;endc; 


F, 


NOCNRPY command */ 


NONS EQACK command */ 


reserved 


reserved 


reserved 


reservec 


reserved 


reservec 


reservec 


reserved 


reserved 


reserved 


/* Go case */ 

/* aqood target */ 
end; /* good checksum */ 

end; /*qood communications with imMQSs*/ 


returnScam(msafptr); 


(msafptr:=raacpt(.holdfslevesex) ) 


return rem(msaf ptr) ; 


/* set failure indicator */ 
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cgeméf(f) = cacmaf(C) or @Ch; 
end; i 


end; /* co forever */ 


cecf$slev;. 
comslvSmodule; 
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Stitle('QUEUE INITIALIZATION PROCEDURE‘) 


OSINITSMOLDULE: Do; 


declere eom literally 'CDH'; 
Sinclude(:fl:commsq.elt) 
Ceclare msafformat literally ‘structure ( 


trot byte, 
cmnd byte, 
seqSla byte, 
seqSna byte, 


text(25C) byte )'; 


Ceclat. queueSformat literally ‘structure ( 


enc$ptr byte, 
givefptr byte, 
tekefptr byte, 


GataSbyte(254) byte )'; 


Ceclare parSformet literally ‘structure ( 


la byte, 
ne byte, 
cun byte, 
stop byte, 


queSpt byte )'; 
Sinclude(:f%:synch.ext) 
ROCGEND: 
PRCCEDURE (EXCHANGESPOINTER,MESSAGFESPCINTER) EXTERNAL; 
DECLARE (EXCHANGES PCINTER,MESSAGESPOINTER) ADDRESS; 


END RQSEND; 


RQWATIT: | 
PROCEDURE (EXCHANGESPOINTER,DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGFSPOINTER,CELAY) ADDRESE; 


END RQOWAIT; 


ROACPT: 
PRCCEDURF (EXCHANGESPOJNTFR) ADDRESS EXTERNAL; 
DECLARE EXCRANGESPOINTER ADPRESS; 


END RQACPT; 


RCIGNLE: 
PROCEDURE (IEDSPTR) EXTERNAL; 
DECLARE IEDSPTR ADDRESS; 


END ROISND; 
Sincluce(:fC:exch.elt) 
DECLARE EXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MSGSHEAD ADDRESS, 
MEGSTAIL ADDRESS, 
TASKSHEAD ADCRESS, 
TACKSTAIL ADDRESS, 
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NEXTSEXCH ADDRFSS) 'p 
Sinclude(:ff:msg.elt) — 
RECLARE MSGSHDR EER er 

LINK ADERESS, .: oe 

LENGTH APDRESS, 

TYPE BYTE, | . 

HOMES EXCHANGE ADDRESS, 

RES PONSESEXCHANGE PORE 


LECLARF MSEGSDESCRIPT aoe LITERALLY. “STRUCTURE ( 
MEGSHDR, 
piieeasn a. BYTE) '; 


eels ve timex euehandes cose rietor external; 
Ceclere rafsrcx exchangesescriptor external; 
CCSQSINIT: Procedure . auenet ptr, queueSsize) reentrant pub 
lic; bos a ; 2 
/* 
This procedure initializes the queue pointers to 
indicate an empty queue. 


*/ 


Declere queuefptr adéress; 
Declere queueSsize yee 


Declare queue based queue! Sptr ‘queues format; 


 .f* set-up the size Of the queue “into the structure a/ 


gueue.FNDSPTR = queueSsize - 1; 
/* ceset the queue offset pointers */ 
| - queue.GIVESPTR,queve.TAKESPTR = 03 
/* return to celling program .*/ 


return; 


end casaq “init 


end oSinitSmocule; 
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Stitle('NEXT GIVE QUEUEF 
NEXTEGIVESMODULE: Do; 


Ceclare eom literel 


PROCEDURE, VERSION 2.1') 


ly 'CDH'; 


Sincluce(:fl:commsg.elt) 


Ceclare msaSfornmat 


trat byte, 
cmne byte, 
seasla byte, 
seqfne byte, 


text (256) byte 


declare queueSformat literally 


endSptr 
giveSptr 
tekeSptr 
Catafbyte (254) 
Ceclare parSformat. 
la byte, 
na byte, 
Lut byte, 
stop byte, 


queSpt byte ) 
Sincluce(:ff:synch.ext) 
RQSENP: 


PRCCEDURE (EXCHANGESPCINTER, MESSAGFSPOINTER) 
LTECLARE. (EXCHANGES POCINTER,MESSAGESPOINTER) 


END ROQSEND; 


RQWAIT: 


literally ‘structure ( 


ee 


"structure ( 
byte, | | 

byte, 

byte, 

byte )'; 


literally ‘structure ( 


EXTFRNAL; 
ADDRESS; 


PRCCFDURE (EXCHANGESPOINTER,DELAY) ADDRESS EXTERNAL; 


DECLARE (EXCHANGES POINTER ,DELAY) 


END ROWAIT; 


ROACPT: 
PROCEDURE 


(EXCHANGES POINTER) 


APDRESS; 


APDRESS EXTERNAL; 


DECLARE FEXCHANGESPOINTER ADDRESS; 


END ete 


ROISND: 
PROCEDURE 


(TEDSPTR) EXTERNAL; 


DECLARE TIFDSPTR ADDRESS; 


~ END ROISND; © 
Sinclude(:ff:exch. elt) 


ee EXCHANGES DESCRIPTOR 


SGSHEAD ADDRESS, 
eee mrar. ADPRESE, 
TACKSHEALD ADDRESS, | 
ee ADDRESS, 


LITERALLY ‘STRUCTURE 
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NEXTSEXCH ADDRESS) '; 
Sinclude(:ff:msq.elt) 
NECLARE MSGSHDR LITERALLY ' 
LINK ADDRESS, °° 

LENGTH APDRESE, 

‘TYPE BYTE,.° |... 

HOMFS EXCHANGE ADDRESS ro 
RES PCNSRSEXCBANGE ADDRESS"; 


DECLARE MSGSDESCRIPTOR LITERALLY ‘'€TRUCTURE ( 
MSGSEDR,  ¢ | 
REMAINDER (1) BYTE) 'j 


declere timex exchangefeescriptor externe1; 
Geclare rcqofsrx exchengeScescriptor external; 


COSNEXTSGIVE: Procedure (QUEUESPTR,GIVFSBYTE) byte reentran 
t Puptye: 

i | : 

This procedure pieces a ‘byte into che cueue if room 

exists in the queue for that byte of cata. If no room 

exists, e queue full indicator will he returned by 

the procecure. : 


*/ 
 Declere QUEUFSFULL literally 'CGFFH'; 
Declare QUEUESOK: literally 'GGCH'; 


Declare QUEUESPTR eddress; 
Declare (GIVESBYTF,RSLT) byte; 


.Geclare queue besed queuveSptr quevefformet; 
/* Test for cueue full condition and if it is full, 
then insert end of messege */ 


RSLT = queueS Sok; : oS eR 
Tf: (Gueue: GIVFEPTR+L > queue. ENDS -PTR) 
then co; 
rslt = aueueffull; 3 
Gueue. sacohyee (eWeues cives pte) = eon; 
enc; 


else do; 


/* Ettore the byte into the next queue location 


i 
queue. Pinte Pee ven se ee) = GIVESBYTE; 
/* Inerement the give pointer 4/ 


Tf ((aueue. CIVESPTR: =queue. GIVESPTR+) 
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> queue.ENDSPTR) 
then cueve.GIVESPTR = 0; 
end; 


/* Return to celling program with aooc complete */ 
Return rslt; 


end cafnextSqive; 
end nextSaiveSmodule; 
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ftitle('GET CHARACTER FRCM toe PROCFDURE') 
NEXTSTAKESMONULE: Po; 


declare eom literally ‘CPH'; 
Sincluce(:flscommsg.elt) 
ceclare msg$format literally ‘structure ( 


trat byte, 
crne byte, 
ee byte, 
seatne byte, 


text(25@) byte )'; 


Ceclere queuef format literally ‘structure ( 


encSptr | byte, 
veo byte, 
takeSptr byte, 


dataSbyte(254) byte )'; 


Ceclare parSformet literally ‘structure f 


la byte, 
na byte, 
run byte, 
stop byte, 


quefpt byte )'; 
Sinclude(:ff:synch.ext) 
ROSEND: 
PROCEDURE (FEXCHANGESPOINTER,MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTER ,MESSAGES POINTER) ADDRESS; 


END ROSEND; 


ROWATT: 
PROCEDURE (EXCHANGFSPOINTER,DELAY) ADPRESS EXTERNAL; 
DECLARE (FXCHANGESPOINTER,PELAY) ADDRESS; 


END RQWAIT; 


ROACPT: 
PRCCENURFE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGESPOINTER APPRESS; 


END ROACPT; 


ROTEND: . 
PROCEDURE (TIEDSPTR) EXTERNAL; 
DECLARE IEDSPTR ADERESS; 


END RQOISND; 
Sincluce(:ffi:exch.elt) 
DECLARE EXC TE NGES Peon each LITERALLY "STRUCTURE ( 
MSGSHEAD ADDRESS, 
MSGSTAIL ADDRESS, 
TASKSEEAD ADDRESS, 
TACKSTAIL ADDRESS 
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NEXTSEXCH ARDRFSS) '; 
Sinclude(:ff:msg.elt) 
PECLARE MSGSHDR LITERALLY ! 

LINK ADDRESS, 

LENGTH ADDREEES, 

TYPE BYTE, _ 

HCMES EXCHANGE ADPRESS, 

RESPONSES EXCHANGE APDRESE's: 


DECLARE MSGSDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MEGSHDR, | 
REMAINDER(1) BYTE) '; 


COSCMEXT. TAKE: 


/* 


i 4 


end 
enc 


Ceclare timex exchangefSeescriptor external; 
Cacl.ere rafsrx exchangeScescriptor external; 


This typed procedure gets the next byte from the 
indicatec queue and returns. it to the callina 
progrem. The cueve take pointer is incremented. 


Declare aueue$ptr aecress; 
Declare tekefhyte hyte;. 


Ceclare queue based cueuefptr oueueSformeat; 


/* store next data byte in queue */. 


takefhyte = queue.DATASPYTF (queue. TAKESPTR) ; 


Procecure (queueSptr) byte reentrent public; 


/* increment the teke pointer to next location */ 


If ( (queue. TAKESPTR:=oueue. TAKESPTR+) 
> queue. ENPSPTR) | 
then queue. TAKESPTR = i; 
/* return the cata byte to caller */. 


return takefbyte;. 


cafnextStake; 
nextStekefmocule; 
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stitle(' PECTI to HEX CONVERSION: PROCEDURE ' oy 
ASCS °"YSMORULE: Do; | 


io) 


2 1 Ceclare eom literally ‘ep 
fincluce(:fl:commsg.elt) oA awe 
Ceclare msaffornet. literally ‘structure | 


3 1 = 
= trot byte, 
= emnn¢c byte, 
= segqtjae hyte, 
= seaftne  hyte, © 
= text (25) hyte )'; 
A 1 = declare cueveS format literally ‘structure ( 
= | ené= ptr byte, 
= divefptr byte, 
= takeSptr byte, 
= dataShyte (254) byte )'; 
5 Le Ceclere perSformet Jiterally ‘structure ( 
= la byte, 7 ; 
= na byte, 
= run byte, 
= BEOP byte, 
= quefpt byte )'; 
Sinclude(:ff:synch.ext) 
6 1 = ROSEND: ; | 
= PROCEDURE (EXCHANGESPOINTER, MESSAGFSPOINTER) EXTERNAL; 
7 2 = PECLARE (EXCHANGESPOINTER ,MESSAGESPOINTER) ADDRESS; 
€ 2 = END RQSEND; 
© 1 = ROQWAIT: 
= PRCCEPURE (EXCHANCESPOINTER, DELAY) ADDRESS EXTERNAL; 
leé 2 = DECLARE (EXCHANGESPOINTER, DELAY) ADDRESS; 
i} 2 = END ROWAITT; 
12 J] = RQACPT: 
= PROCEDURE (EXCHANGESPCINTER) ADDRESS EXTERNAL; 
es 2 = DECLARE EXCHANGESPOINTER ADDRFSS; 
it B & END RQACPT; | 
LS 1 = ROISND: 
= PROCEDURE (IELDSPTR) FXTERNAL; 
1% 2 = DECLARE IEDSPTR ADDRESS; 
17 2 = END RQOISND; 
Sinclude(:fC:exch.elt) 
1 ] DECLARE EXCHANGESPESCRIPTOR LITERALLY ‘STRUCTURE ( 


MSGSHEAD ADDRESS, 

MSCSTAIL ADDRESS, 

uaa ADDRESS, 
SKSTAIL ADDRESS, 
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20; 


ba be ps 


| 


NEXTSEXCH ADDRESS) '; 
Sinclude(:fC:msaq.elt) 
DECLARE MSGSHDR LITERALLY ' 
LINK ADDRESS, 

LENGTH ADDRFSS, 

TYPE RYTE, 

HOMES EXCHANGE ADDRESS, 

RES POCNSESEXCHANGE ADDRESS'; 


DECLARE MSGSDESCRIPTOR LITERALLY 'fTRUCTURE ( 
MSCSHDR, 
wor AINDER(1) BYTE) '; 


declere timex exchaengeScescriptor external; 
Geclere rafsrx exchanaeSdescriptor external; 
cafnextStake: 
procecure (afSptr) byte external; 
declare q$ptr acdress; 
enc cqfnextStake; 


COSASCSHEX: Procecure(qSptr,msgSptr) reentrent public; 


/* 
This procecure transforms ASCTI cata in the input 
queue into @ hex string in the system message storage 
area, 7 


sl 
Declere (nchar,cher,n) Eyte;. 
Declere (q$ptr,msqfSptr) acdress; 


Ceclare msq hased msqfptr msaqfformet; 


/* throw awey the start of message */ 
cher = eqSnextStake(qfptr); 


/* convert messege target edcress */ 
cher = cqSnextStake(qSptr); 
ncher = cafSnextStake(qtptr); 


1f char > 4C€h 
then char = cher - 37h; 
else char = cher - 26); 


if ncher > 4€h 
then nchar = nchar - 27h; 
else nchar = nchar - 2¢h; 


msa.trgt = shl(char,4) + ncher; 


/* convert command byte */ 
char = caSnextStakelafptr); 
if cher > 4Ch 

then char = cher - 37h; 
else char = char - 2€h; 
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msa.cmnd = char; . 


/* convert LA sequence */ | 
cher = cqfnextStake(qfptr) 7 


if cher > 46h 
then cher = char ~- 27h; 
else char = cher - 2fh; 


msg.seq¢tla = cher; 


/* convert MA sequence */ 
char = cqSnextSteake(aSptr) ; 


if char > 4h 
then char = cher = 27h; 
else char = char - 2h; - 


msg.seq$ne = cher; 
“/* do operations until end of message */ . 


n= @; 
Do while (char:=cqfnextftake (Ofptr) ) <> FOM; 


/* get next ASCII character */ 
nchar = cqSnextfteake(OSptr) ; 
/* convert to hex format */ 
if char > 4¢H 
then char = char - 37H; 
else char = char - 3CH;_ 
if nchar > 4¢H 


then nchar = ncher - 378; 
else nchar = ncher '-. 320K; 


msq.text(n) = shli(char,4) + nehar; 
n=n + 1; ca ro 
end; 


enc cafescfShex; 
end ascShexSmodule; 
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¢title("HEX TO ASCII CONVERSION PROCEDURE") 
HEXSASCSMODULE: Po; | 


‘eclare eom literally 'CDH'; 
Sinclude(:flscommsg.e]t) | 
Geclare msqSformet literally ‘structure ( 


trat byte, 
cmnd byte, 
secSla byte, 
seoSne byte, 


text (25C) byte )'; 


declare aueueSformat literelly ‘structure ( 


endSptr byte, 
giveSptr byte, 
takeSptr byte, 


dataSbyte(254) byte )'; 


declare parSformat literally ‘structure ( 


la byte, 
ne byte, 
run byte, 
SEOP byte, 


que$pt byte )'; 
Sinclude(:ff:synch.ext) 


— ROSEND: 


PRCCEDURE (EXCHANGESPCINTER, MESES AGES POINTER) EXTERNAL; 
DECLARE (EXCHANGES POINTER , MESSAGFS POINTER) ADDRESS; 


END ROQSEND; 


ROWATT: 
PROCEDURE (FXCHANGESPCINTER,CDCELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGES POINTER,DELAY) ADDRESS; 


END ROWAIT; 


ROACPT: | 
PROCEDURE (EXCHANGESPOINTER) ADPRESS EXTERNAL; 
DECLARE EXCHANGESPOINTER ADDRESE; 


END ROACPT; 


ROIEND: 
PRCCEDURE (ITEDSPTR) EXTERNAL; 
Eee IEDSPTR APDRESS; 


END ROIEND; 
Sinclude(:ffs:exch. elt) 
DECLARE EXCHANGESDESCRIPTCR LITERALLY ‘STRUCTURE ( 
MSGSHEAD ADDRESS, 
MEGSTAIL ADDRESS, 
TASKSHEAP ADDRESS, 
TASKSTAIL ADDRESS, 


2-225. AFN-01931A 


APPENDIX D. 


26 
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NEXTSEXCH APDRESS 3 
Sincluce(:ff:msq. ae) 
DECLARE MSGSEDR Lic eRe res a 

LINK. ADDRESS, a 

LENGTH ADDRESS, 

TYPE- BYTE, | 

HOMES EXCHANGE ADDRESS, 

RESPONSES EXCHANGE ADDRESS ; 


DECLARE MSGS DESCRIPTCR LITERALLY "STRUCTURE ( 
MSG HDR, a 
nee DLE) PYTE)'; ke te 

declére timex exchanoeSdescriptor external; 

Ceclare rqfsrx exchengeScescriptor externe]; 


cqfnextfgive: : | 
procedure (quefptr, deteSbyte) byte external; 
Geclare queSptr address; 
Cecléere dataSbyte byte; 

end caSnextSqive; 


COSHEXSALCC: Procecure (qfptr,hex<Sbyte) reentrent public; 


/* 
This procedure is used to convert e@ hex byte into two 
i ASCII cherecters and store them into the next two loc- 
ations of the OSout cate erea. | 
a7, 
Declere oD oye hexSbyte, lowSbyte,stetus) byte; 
Declare q$ptr address; 


Declere agout based afptr queue$format; 
/* separate low anc high order bits */ 
If (high$byte:=(shr(hexSbyte,4) end CFR)) > © 


then highSbyte highShyte + 27H; - 
else highSbyte highSbyte + 2H; 


Tf (lowSbyte:=(hexShyte and ern > : 
then lowSbyte = lowfSbyte + 27H; 
else lowSbyte = lowSbyte + 20H; 


/* store ASCII conversions into the queue * / 


status = cqfnextSgive(.QScuT, highfbyte); 
status = cqSnext$aive(.QSouT, lowfbyte); 
feturnp = 
end caShex$esc; 
end hexSascfmodule; 
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Stitle ("CHECKSUM CALCULATION PROCEDURE" ) 


CHECKSUMSMODULE: fo; 


Ceclare eom literally ‘EDN; 
Sinclude(:fl:commsg.elt) 


declare msq$formet literally ‘structure ( 


trot byte, 
cmne byte, 
seqfla "ete, 
seqgina byte, 


text(25) byte )'; 


Ceclere queveSformat literally ‘structure ( 


end&ptr byte, 
giveSptr - byte, 
takeSptr byte, 


CatasSbyte(254) byte )'; 


Ceclare perSformat literally ‘structure ( 


la byte, 
na — byte, 
run byte, 
Step ? byte, 


quefpt byte )'; 
SPeMide (: fM:synch.ext) 
ROSEND: 


PRCCEDURE (EXCHANGES POINTER, MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGES POINTER, MESSAGESPOINTER) ADDRESS; 


FND ROSEND; 


ROWATTs 


PROCEDURE (EXCHANGES *POINTER , DELAY) ADDRESS 


TECLARE (FXCHANGESPOINTER,DELAY) ADDRESS; 


END ROQWATT; 


RQACPT: 


PROCEDURE (EXCHANGESPOTNTER) ADDRESS 


DECLARE EXCHANGESPOINTER ADDRESS; 
END ROACPT; 


ROISND 
PROCEDURE (IEDSPTR) EXTERNAL; 
DECLARE IECSPTR ADPRESS; 


END RQISN | 
Sinclucde(: a ee Ae 
DECLARE ERE Gre Dee Ney oe LITERALLY 
MSGSHEAD ADDRESS 
MSGSTAIL ADDRESS, | 
TACKSHEAD ADDRESS, 
TAEKSTATL APDRESS, 
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NEXTSEXCH APDRESS) '; 

Sincluce(:ff:msq.elt) 

DECLARE MSGSHDR LITERALLY ' 
LINK ADDRESS, ok 
LENGTH ADDRESS, 

TYPE BYTE, . 
HOMESEXCHANGF ADDRESS, Gee 
RESFONSES EXCHANGE ALDRESS'; 


DECLARE MSGEDFSCRIPTOR LITERALLY ' STRUCTURE ( 
MSCSHDR, eer : 
REMAINDER (1) BYTE) * 


declare timex. eehangecdesar inter: eure rast 
CGeclare roafsrx exchangeScescriptor external; 
COSCHECKSUM: Procedure(qfptr) byte reentrent public; 


ad : 
-This procecure is used to determine the checksum of 
a message which has been received and stored into 
the QCSin buffer. A checksum will he calculated on ell 
characters beqinning et the start of text and 
continuing until the checksum bytes are encountered. 
This value will be testec with the value transmitted 
and if they egree, a value of zero will be returned 
to the calling program. If not in econ e 
non- "ZELO velue will be- feturned. 


Declare (ptr,endSptr,q£ aoe eddress;. - 
Declare (checksm,strina$sum,cher,n) ee 
gee ee eae a ane moka a ae 


—@eclere aqSin- besed afptr aueues Sescnets 
/* get queue poin’'er values for reference */ 


PTR = OSIN. takeSptr; 
“ENDSPTR = “QEIN. end’ ptr? 


al ia aes checksum velue +) 
checksm = §&; 
/* compute checksum of string */ 


char = QOSIN.datafhyte(ptr); 

Co while char <> FOM; ran 
checksm = checksm + onan 

“EF ptr = pans ani | 

then ptr = Gp. 
else ptr = ptr + 1; Mert : 
char = QSIN. datachyte (pte); 

end; 
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/* last three charecters in the message ere 
not includec in the checksum, so they must 
be subtracted....*/ 


/* first remember the lest queue location */ 
if ptr = encfptr 
then cher = (; 
else cher = ptrt+l; 


Po n= £ to as 8 . 
checksm = checksm - (last€chers(n):= 


if ptc = fF 
then ptr = enefptr; 
else ptr - ,tr - J; 
end; 
checksm = checksm + lest€chars(f); 


/* convert transmittec checksum into 2 hex velue */ 


Do n= 1 to 2; 
if least€chars(n) > 4CH | 
then lestSchers(n) = last€chers(n) - 27H; 
else lastfchers(n) = last$chears(n) - .20H; 
ends 
stringSsum = shl(lastSchers(2),4) + last$Schers()); 


/* test for validity. of transmission * / 


if stringSsum = checksm 
then return 1; 


/* if bad checksum, clear date queue of message */ 


else CSTN.tekeSptr = cher; 
retucn -1]; 


enc caSchecksum; 
ene checksumSmodule; 
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—€title('GENERATF PEADY MESSAGE PROCEDURE’) 


GENSRDYSMCDULE: Do; 
Ceclare eom literally ‘OpH'; 


Geclare msgSformat literelly ‘structure ( 


trgt byte, 

emnd byte, 

seqSla byte, 
 seasna byte, 
ss byte )'; 


Ceclare queveSformat literally 'structure ( 


endSptrc 
givefptr 
tekeSptr 


dataSbyte (254) 


byte,. 
byte, 
byte, 
byte )'; 


—ROQWAIT: 


Huu ht tt bom tn How WoW tt, 


declare 'perSformat "structure ( 
le byte, 
na | byte. 
run | byte, 
— stop byte, 
| quefpt byte )'; 
Eenebuee f('zsynch.ext) 
ROSEND: 
PROCEDURE 
| DECLARE 


literally 


(EXCHANGES POINTER ,MFRSSAGES POINTER) EXTERNAL; 
(EXCHANGES POINTER ,MESSAGESPCINTER) ADDRESS; 


END ROSEND; 


(EXCHANCESPOINTER,DELAY) ADDRESS EXTERNAL; 
(EXCHANGES POINTER,DELAY) ADDRESS; 


PROCEDURE 
DECLARE 


END RQOWAIT; 


RQACPT: 
PROCERURE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGESPOINTER ADDRESS; 


END ROQACPT; 


RQIEND: 
PROCEDURE (TEDSPTR) EXTERNAL; 
DECLARE IEDSPTR ADDRESE; 


END RQISND; 

Sinclude(:f@:exch.elt) 

RECLARE EXCHANGESDESCRIPTOR LITERALLY 
MSGSHEAD ADDRESS, | | 
MSCSTATIL ADDRESS 
TASKS BREAD ADDRESS, 

TASKSTAIL AFDRESS, 


"STRUCTURE ( 
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NEXTS EXCH ADDRESE)'; 
Sincluce(:fl:msq.elt) 
CECLARE MSGSHDR LITERALLY ‘° 
LINK ADDRESS, 

LENGTH ALCPRESE, 

TYPE BYTE, 

HOMESEXCHANGE ADDRESE, : 
RESPONSESEXCHANGE ADDRESE'; 


DECLARE MSGEDESCPIPTOP LITERALLY 'STRUCTURE ( 
MSCSEDR, 
REMAINDER(1) BYTE) '; 


declare timex exchanaeSdescriptor external; 
Ceclere rafsrx exchangeScescriptor external; 


cqfmsqfout: 
procecure (msoSsize,afptr,parfptr,msgqSptr) external; 
declare msaqSsize byte; 
CGeclare (qSptr,parSptr,msgfptr) aderess; 

enc cafmsgfout; 


COSGENERDY: Procedure (trget,msaSptr,aSptr,parSptr) reentr 
ant public; 


/* 
This procedure generates a "ready" message onto the 
communication network. The target address is passed 
as the peremeter in the call. 
On entry to the procedure: 
trget is a hyte which contains the address 
of the target node. 
msgSptr is an address which points to 
the RAM work erea. 
a$ptr is an aderess which points to 
the output queue. 
perfptr is an edéeress which points to 
the communicetion flags. 
ay 


Neclere trget byte; 
Reclare rcySmsg structure ( 


TARGET byte, 
COMAND byte, 
SEQSLA byte, 
SEQSNA byte ) 


Gata ( ¢,3,0,8 ); 
declare (msafptr,gSptr,parSptr) address; 
Geclare msg hesedc msaSptr msgSformat; 


/* move format into message block */ 
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enc 
end 


call move (4,.rdyfmsq,msacptr) zs 

/* insert current. parameters. */ 

msg.trat = treet; as 

/* send messege */ 

cal] acemegsene 16: Seon aeons eee eee 


return; 
cqfaent recy; 


genSreySmodule; 
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f€title('DATA MESSAGE GENERATOR PROCEDURE') 
GENSMECSMCDULE: Do; 


Ceclere eom literally 'DH'; 
Sinclude(:fl:commsg.elt) 
Ceclare msqfformat literally ‘structure ( 


trot byte, 
cmnd byte, 
seqfla byte, 
seofna byte, 


text(258) byte )'; 


declare queuveSformat literally ‘structure ( 


encSptr hyte, 
qivefptr hyte, 
takeSptr byte, 


CataSbyte(254) byte )'; 


declere parSformat literally ‘structure ( 


la byte, 
ne byte, 
run byte, 
stop byte, 


aueSpt byte )'; 
Sinclude(:ff:synch.ext) 
ROSEND: 
PROCEDURE (EXCHANGES POINTER,MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTER,MESSAGEFSPOINTER) ADDRESS; 


END ROSEND; 


ROWATTs : 
PROCEDURE (EXCHANGESPOCINTER,PELAY) ARDRESS FXTERNAL; 
DECLARF (EXCHANGFSPOTNTER,DELAY) ADDRECE; 


END RQWAIT; 


RQACPT: 
PROCFPURE (EXCHANGESPOTNTER) ALPDRFESS EXTERNAL; 
DECLARE EXCHANGFSPOINTER ADDRESS; 


FND RQOACPT; 


RQTEND: 
PROCEDURE (IFDSPTR) EXTERNAL; 
DECLARE IFEDSPTR ADDRESS; 


END ROISND; : 
Sinclude(:fC:exch.elt) 
DECLARE FXCHANGESDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MSGSHEAD APDRESS, 
MSGSTAIL APERESC, 
TASKSHEAD ADDRESS, 
TASKSTAIL ADPRESS, 
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NEXTSEXCH. ADDRESS) '?3 | 
Sinclude(:ff:msaq.elt) 
PECLARE MSCSHDR LITERALLY ! 

LINK ADDRESS, 

LENGTH ADDRESS, 

TYPE. UEY Les 

HCMES EXCHANGE ADDRESS, 

RESPONSES EXCHANGE BOLERO 


DECLARE MECSPESCRIPTCR LITERALLY 'STRUCTUPR I 
MSGSEDR, oa 
REMAINDER(1) BYTE) '; 


Ceclare timex exchangeSdescriptor externel; 
Ceclare: rafsrx SkCheng ex CEECETPEOE external; 


ceSmsgSout: 
procedure (msgSsize,aSptr,perSptr,msgSptr) external; 
declare msaqS$size byte; : 
Ceclare (afptr,parSptr,msqSptr) ‘adcress; 

end cafmsafout; 


COSGENSMSG: Procedure (msqfpointer, traet, msgSptr, oSptr, 
parfSptr,saveffla) reentrant public; 


/* 
- This procedure aeneretes @ date message and places 
it onto the system communications network. 
On entry to the procedure: 
msgS$pointer is en acdress which points to 
the data to be transmitted. © | 
trget is an byte whick conteins the 
acedress of the teraet node. — 
msgSptr is an address which points to 
the RAM work aree. 
afptr is an ederess which points — 
the output queue. 
perSptr is én aecress which points to 
the communications fleqs. | 
a7 


Declare (msqfpointer,msgfptr,aSptr,parfptr,ramSsize) a 
cdress; 

Declere (trget,saveSflqa) byte; 

Declare msq based msqfptr nmsgfformat; 


Declare datafmsq structure ( 


target byte, 
comand byte, _ 
seaSLA byte, 
seaSNa byte, 
text byte ) 


Geta 1(6,2,¢ £40) 
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Ceclare datefSblock based msqS pointer structure ( 
msafher ); 

/* move message format into messaqe buffer */ 

cell move (&, .catefmsa, msasptr); 

/* insert target edcress */ 

msg.traqt = traet; 


/* append date to communicétion message */ 


cell move (Aatafblock.length, msafpointer, .msg.text (— 


/* transmit messege onto network */ 


ram&size = detaSblock.length; 
call caqfmsgSout (ramfsize,qSptr,parfSptr,msgqe ptr) ; 


/* return memory to free space maneger */ 


if saveSflq 
then co; 
if ramsize mod 4 > f£ 
then CateSblock.lenath = cetefblock.length + (4-(r 


emSsize mod 4)); 


end 
end 


call RQSEND (.rqfsrx, msaSpointer); 
end; 


return; 


cqSgenfomsg; 
genSnsaSmocule; 
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Stitle('iSEX 35) COnnunicet TONS Driver, Version 1.2") 
Snointvector “% 
] “CCEA S le Noe 


JR RRERRERKEREREFERER ERE RRR EKER RE RRR RERER ERE RE RE RERREKRKKEEKEEE 


This module contains the physical interfece for 
Support of the Intel iSBX 351 communications expansion 
boerd. The board is insertec into socket JS anc has a 
base address of F@H with the interrupt from the 
receiver strapped to the interrupt level %. The 
trensmitter interrupt is wiree to interrupt level §&. 


Multi-@rop communication options are supported by 
the physical softwere package. 


KHKKKKREKEKERR EKER ERE REE ERIE REE KERRIER EERE ERK IK / 


Sinclude (:ff:exch.elt) 
DECLARE EXCHANGESDESCRIPTOR LITERALLY 'STRUCTURE ( 
MSGSHEAD ALDRESE, 
MSGSTATIL ADDRESS, 
TASKSHEAD ADPRESS, 
TASKS TAIL ADDRESS, 
 NEXTSEXCH ADDRESS)! 
Sinclude (:ff:ied. elt) 
DECLARE INTSEXCHANGFS DESCRIPTOR LITERALLY “STRUCTURE ( 
MESSAGESHEAD ADDRESS, 
MESSAGESTAIL ADDRESS, 
TASKSHEAD ADDRESS, 
TACKSTAIL ADDRESS, 
EXCHANGFSLINK ADDRESS, 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE RYTEF)'; 
Teclere RCLSEX intfexchenoeSdescriptor external; 
] Leclere ROL7EX intSexchangeSeescriptor external; 


tJ 
— 


CA us 
—_— 


Sinclude (:flscommsa.e!]t) 
6 J = Ceclare msafformat literally ‘structure ( 
trat byte, 
cmne byte, 
seafla byte, 
seaSna byte, 
text(25f) byte )'; 


~J 
a) 


Ceclere quevefformat literally ‘structure ( 
endc$ptr byte, 
givefptr byte, 
tekefptr byte, 
datefSbyte (254) byte )'; 


tou uw t ton 


Ceclere parfformat literally ‘structure ( 
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= Je: <«- byte, 
= ne hyte, 
= ran byte,. 
VOR byte, 


i 


~ aqueSpt byte .)'3) 
neeiace COINSL Cueves hornet external; 
Declare CQOQUTSL aueueSformat eyrerna is 
RNeclare CQOPARS parSformet external; 


Sinclude (:fl:comcom. ent) 


_COSNEXTSGIVE: 


-Procecure (af Oe ay Iv COBY NE) byte external; 
Teclare afptr address; 
Declare aivefbyte byte; 
enc caSnextSgive; 
COSTAKESTEST: 
Procedure (qfptr) byte enema 
Declare aSptr address; . 
end caStekeStest; 

COSNEXTSTAKE: a 
Procedure (qfptr) byte externel; 

Declere q$ptr adcress; 
end a a 3 

COSOSINIT: Loe an 
Procecure (q§ ptr, aes size) externa al; 
Declare gSptr eddress; | | 
Declare qSsize byte; a 
end casaqs$init; 

COSASCSHEX: , : ae 
Procedure (qSptr, gece éptr) externel; 
Declare (q$ptr,msqa$ptr) address; | 
end casaescfthex; 

COSCHECKSUM: 

Procedure (qfptr) byte externel; 
Declare qfptr eaccress; 
end cafchecksum; 

COSHEXSAEC: 
Procecure (ofptr,hexfhyte) external; 
Reclare aqfptr ecdress; 

Declare hexSbyte hyte; 
enc caShexfesc; 

COSMSCSCUT: 

Procecure (msgfsize,cfrtr,perfptr,msgqf ptr) external; — 
Neclere msqSsize Pye 

Declere (afptr,pars Erne Pete eccress; 

enc cafmsgfout; > : 

COSCEMSRDY: eh ao 
Procedure (traet,msafptr,cfptr,perfptr) externel; 
Peelare: trget. byte; 

Neclare (msqfptr,aSptr,parSptr) accress; 
end cqfaentrdy; 

COSGENSMSG: - 
Procecure (msgSpointer, trget, msgs ee es ptr, pers eptr, sav 

efflq) externel; 

Declare (traet,seveffigq) byte; 
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PReclere neo: pointer, meg: Sptr,aqSptr,perfptr) adcress; 
enc cafaenftnsg; | 
Sinclude (: F':synch. ext) 
ROSEND : 
PRCCEDURE (EXCHANGESPOINTER, MES SAGES POINTER) EXTERNAL; 
DECLARE (EXCHANGES POINTER, MESSAGFSPOINTER) ADDRESS; 


END RQSEND; 


RQWATT: 
PROCEDURE (EXCHANGES POINTER; DELAY) ADDRESS EXTERNAL; 
“DECLARE (EXCHANGFSPOINTER, DELAY) ADDRESS; | 


END ROQWAIT; 


ROACPT: 
PROCEDURE (EXCHANGFSPOINTER) ADDRESS FXTERNAL; 
DECLARE EXCHANGESPOINTER ADDRESS; 


END ROACPT; 


RQOISND: 
PROCEDURE (TEDSPTR) EXTERNAL; 
DECLARE IFDSPTR ADDRESS; 


END ROISND; 
Sinclude (:ff:intrpt.ext) 
ROENDI: 

FROCEDURE EXTERNAL; 


END ROENDT; 


RQELVL: 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; . 


END RCELVL; 


RQDLVL: 
PROCEDURE (LEVEL) EXTERNAL; 
DECLARE LEVEL BYTE; 


“END RODLVL; 


ROSETV: 
PROCEDURE (PROC, LEVEL) EXTERNAL; 
DECLARE PROC ADDRESS; 
DECLARE LEVEL PYTE; 


END ROSETV; 
ROSETP: 
PROCEDURE (PROC,LEVEL) EXTERNAL; 


DECLARE PROC ADDRESS; 
DECLARE LEVEL PYTE; 
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END ROSETP; 


Declare EOM literally 'CDH'; 


/* defines end of message * / 
Declare RTS literally 'AEIFAOEEb'; 
/* ready to send to USART */ 


Declare RXE literally ‘@CCFRICEb'; 
/* ready to receive to USART */ 
Declare DTR Jiterally ‘'CFFOCHICb'; 
/* data set ready to USART */ 
Declare TXEN literally 'MEFGECCIb'; 
/* transmit eneble to USART */ 

Teclere hedint byte; 
/* fleg for interrupt 5 * / 


Seject 
[RRR IR IRR RRR RIOR TR IR IR TOR IR TOR KIO T TIT RRTTK ERI RR EAR IR RE 


This procedure initielizes the hardware reaquiree to 
operate the iSPX 251 expansion boerc. 


KKEKKKKKERKEKEKEKE KK EKER KEKE KR ERERERKE ER EEKREKEK ERR KEE RERERKEEE / 


COSINITS 251¢ 
| Procedure public; 
Declare n_ byte; 


/* initialize the timer/counters */ 

output (Cfbh) = €b6h; /* select counter 2 */ 
output (Nfah) = 322; J* lsh for 2476 beud */ 
output(Cfah) = 0; J* msb for 240 baud */ 


7/* initialize the USART #*#/ 


output (Mflh) = @fH; /* clear out garbadqe */ 


output (€@flh) C; /* ... more gerbade */ 
output(nmflh) = 4h; /* reset the USART * / 
output ((fFlh) = fceh; /* ® bit, no perity, ? st 


op */ 


output (CF f1h) /* enable receive moce */ 


| 
NO 
=>) 
ew 
=e 


/* tell the nucleus the vector location*/ 


CALL rqsetv(.caqmivtS3251, 4%); 
cell rasetv(.senéSchar$25], 5); 
c@éll rgelvl( 5); 
cell rqelvl(4); 
return; 
end cqSinit©2?51; 


¢ e 
Fejyect . 
SJ RREEREKEEREKREKKEREREERKEEREREREKEERER ERK EREREREKEKRKEKEKKERERKKKER 


This procedure stores @ character from the USART into 
the receiver data input queue. 
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COMIVTS 351: 


Procecure interrupt © public; | 
Declere (GIVES Pee curiae ey ee 


/* get cherecter from USART - */ 

char = input (fFOh) anc C7Fh; | 
giveSstatus = eqs Snextgive(. eqinsl, char); 
if cher = eom | | | 
then call raisnd(. rol6ex); 

else call rgendi; 


enc camivt$251; 


Seject 
[J RRRKKEKEKRKKS KRKEEKEKEEKKKEEREKKEKKEKEKEKEKEKEKEKEKRKEEKKRKKEKAREKKKKKE 


This procedure sends out the next cheracter to the 


selected USART device. It will Cisable the interrupt 


when all desired cheracters have heen transmitted. 


LNERAHEAAAERERRERA AREAS ERAAD HADES ARN ER ER ER ERE RED ER BOER EES 
-SENDESCHARS351: 


Procedure interrupt 5 public; 
Declare char byte; 


/*testina if interrupt is really for 5 and not noiset/ 
if bedint > # then do; 


/* enable drivers at beginning of messeqe */ 
Tf not capers.run 
then do; 
capers.run = J; 
copars.stop = C; 
end; | es 


aa disable Crivers et end of message 7 
If cqpers.stop 


then Co; 
capars.run = '; _ | 
Do while Ne enc 4) = f; 
end; © | 


badint = @; 
output(@Flh) = 26h; 
end; 7 ss 


/* if message is in progress, send next cherecter */ 
else do; . | 
cher = caSnextftake(.cgqoutsl); 
Co while (input(Mflh) ane 4) = &; 
enc; OS | 
output (OF Ch) = cher; 


/* test for end of messede. t/ 
if (char and Afk) = eom 
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then cqpers.stop 
else ccpars.stop = ¢ 
end; 
enc; 


I 
Samad 
=e te 


/* re-enable interrupts */ 
call raqenei; 


return; 


enc seneSckarf25]; 


¢ e 
Seject 
JR RRR RR TORR TOTO TOTTORI TOR TORTI TOTO RIOT TOR TOR TR RE 


This procecure begins the trensmission to @ selectec noce. 


RE EKKEKEREE KEKE KKEREKEEEKERKEKE EK EERE EREKREERKREREEREREKEKEEEE / 


COSSTARTSMSGS 351; 
Procedure public; 


bedint = @ffh; 
output((Flh) = 25h; 
return; 

enc caSstartSmsq$35] 


=e 


enc’ cas3&l; 
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INTRODUCTION 


An application system based on a custom hardware 
design will typically perform faster and require less 
hardware than if it were implemented with ‘‘off the 
shelf’? circuit boards. However, these advantages are 
countered by the disadvantages of custom designs, with 
one of the largest drawbacks being the custom software 
required. This software is often unique to the applica- 
tion and specific to the hardware design, requiring a 
significant and increasing percentage of the develop- 
ment schedule and expense. The cost is multiplied by the 
need for software tools, standards, and maintenance 
developed specifically for each application. In addition, 
much of the application software cannot be used for 
new applications or hardware. All of these disadvan- 
tages can be significantly reduced by using a modular, 
standardized operating system. 


The operating system provides a higher level interface to 
the system hardware. The hardware characteristics com- 
mon to most applications, such as memory management 
and interrupt handling, are handled by the operating 
system rather than the application software. The 
operating system provides scheduling and synchroniza- 
tion for multiple functions, allowing application code to 
be written in independent pieces or modules. The 
operating system interface can be more standardized 
then the interface to the hardware components. This 
allows. the application software to be more independent 
of changing hardware. The application code can be in- 
itially implemented and debugged on proven hardware. 
The software is then easily moved to the final hardware 
configuration for testing. 


AP-110 


The operating system interfaces allow the use of stan- 
dard software tools, such as debuggers. Operating sys- 
tems also provide decreased debugging time and in- 
creased reliability through error checking and error 
handling. Perhaps most important, the expertise gained 
can be carried on to new designs based on the operating 
system. 


Operating systems have generally been described as 
large and complex, with rigid system requirements. 
Users have found it difficult to tailor a system to their 
needs or to use the operating system on more than one 
hardware configuration. System software has been ac- 
cepted in large pieces or as a whole, with few system 
configuration choices in either hardware or software. 
Those systems small enough to use on component de- 
signs have lacked extendibility to larger, more complex 
designs. 


The Intel iRMX 86 Operating System offers users of 
component hardware all benefits of operating systems 
while imposing few hardware restrictions. Minimum 
hardware requirements include 1.8K RAM memory, 
enough RAM or EPROM memory to hold the Nucleus 
and the application code, and a handful of integrated . 
circuits. The circuits are an Intel iAPX 86 or iAPX 88 
Central Processing Unit, an Intel 8284 Clock Generator, 
Intel 8282/83 Latches for bus address lines, an Intel 
8253 Programmable Interval Timer, and an Intel 8259A 
Programmable Interrupt Controller. Larger system 
busses will also require an Intel 8288 Bus Controller and 
Intel 8286/87 Transceivers for data lines. This basic 
hardware system is shown in Figure 1. 


8259A INTERRUPT LINES 


PROGRAMMABLE 
INTERRUPT 


CONTROLLER 


Fa i es <= | 
CONTROL LINES SYSTEM 
BUS 


8288 BUS 
CONTROLLER 


ADDRESS LINES 


crack - 8088/8086 C=  gogaigs 
GENERATOR CPU LATCHES 


DATA LINES 
8286/87 
_ TRANSCEIVERS 


Figure 1. Basic Hardware System for the iRMX 86™ Operating System 
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Users. with a wide range of applications will find the 
iRMX 86 Operating System allows them to implement a 
corresponding range of capabilities, from a minimum 
iRMX 86 Nucleus to a high level human interface. A 
complete iRMX 86 Operating System includes extensive 
I/O capabilities, debugger, application loader, boot- 
strap loader, and integrated user functions. This flexi- 
bility allows one operating system to be used for many 
projects, minimizing ecrEWare learning curves for new 
applications. 


This note discusses a relatively small standalone spec- 
trum analysis system based on a subset of the iRMX 86 
Nucleus. The intent of the note is to demonstrate advan- 
tages of using operating. systems in hardware compo- 
nent designs. An overview of operating system func- 
tions is given first as background information. Readers 
familiar with operating systems may wish to skip this 
section. The overview is followed by a summary of the 
iRMX 86 Operating System. The summary is brief, as 
only the iRMX 86 Nucleus is used in this application. A 
detailed discussion may be found in Application Note 
AP-86, ‘‘Using the iRMX 86 Operating System,’’ and 
iRMX 86 System Manuals. 


The spectrum analysis system is described after the sum- 
mary. The system requirements, design and implemen- 
tation are detailed. The system software is discussed 
next, followed by configuration and hardware imple- 
mentation. A summary completes the application note 
text. Partial code listings of the system software are in- 
cluded in the appendices. 


OPERATING SYSTEMS FUNCTIONAL 
OVERVIEW 


Operating system software manage initialization, 
resources, scheduling, synchronization, and protection 
of tasks or functions within the system, as well as pro- 
viding facilities for maintenance, debugging, and 
‘growth. In general, operating systems support many of 
the following: 


Multiprogramming 


Multiprogramming provides the capability for two or 


more programs to share the system hardware, after . 


being developed and implemented independently. 
Within the environment of an operating system, the 
programs are called jobs. Jobs include system resources, 
such aS memory, in addition to the actual program 
code. Multiprogramming allows jobs that are required 


only during development, such as debuggers, to run in 


the target system. When development is completed, 
these jobs are removed from the final system without af- 
fecting the integrity of the remaining jobs. . 
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Multitasking 


Multitasking allows functions within a job to be han- 
dled by separate tasks. This is particularly valuable 
when a job is responsible for multiple asynchronous 
events or activities. One task can be assigned to each 
event or activity. Tasks are the functional members of 
the system, executing within the bounds of a job en- 
vironment. Program code for a multitasking system is 
modular, with well-defined interfaces and communica- 
tion protocols. The modular boundaries serve several 
important purposes. The code for each module can be 
generated and tested independent of the other modules. 
In addition, the boundaries confine errors, speeding | 
debugging and simplifying maintenance. 


Growth 


The modular independence that results from multipro- 
gramming and multitasking gives users the ability to ef- 
ficiently create new applications by adding functions to 
old software. Applications can be tailored to specific 
needs by integrating new modules with previously- 
written general support code. If care is taken in system 
design, functions can be added in the field. Documenta- 
tion for the older software can be carried on to the new 
applications. This growth path will save completely re- 
writing expensive custom software for each new applica- 


tion. 


Scheduling 


Even though a system has multiple jobs and tasks, only 


one task is actually running on the central processor at 
any single point in time. Scheduling provides a means of 
predicting and controlling the selection of the running 
task from the tasks that are ready to run. Basic sched- 
uling methods include preemptive priority, non-pre- 
emptive priority, time-slice, and round-robin. Batch 
systems often use non-preemptive priority scheduling, 
in which the highest priority job gets control of the cen- 
tral processor and runs to completion. Preemptive 
scheduling is typically used in real-time or event-driven 
systems, where dedicated, quick response is the main 
concern. A higher-priority waiting task that becomes 
ready to run will preempt the lower-priority running 
task. Priority may be either set at task creation (static) 


or modified during running of the task (dynamic). 


Time-slice and round-robin scheduling are used in 
multiuser or multitask systems that share processing 
resources and have limits on maximum execution time. 
Time-slice scheduling gives each task or job a fixed slice 
of dedicated processor time. Round-robin gives each 
task or job a turn at using the processor. The time avail- 
able during the turn cian on aystem load and task 


priority. 
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Communication and Synchronization 


Jobs and tasks in a multiprogramming and multitasking 
environment require a structured means of communica- 
tion. This communication may be necessary to syn- 
chronize processes or to pass data between processes. 
Two means of providing communication are mailboxes 
and semaphores. Mailboxes are an exchange place for 
system messages. The messages may include data or 
provide access to other system objects, including other 
mailboxes. Tasks can send objects to a mailbox or wait 
for objects from a mailbox. Generally, the task has the 
option of waiting for a specified period of time for the 
message. The wait time may range from zero for a task 
that requires immediate response to infinite time for a 
task that must have a message to continue processing. 
Multiple mailboxes are used to synchronize multiple 
tasks. 


A communication flow using mailboxes is shown in Fig- 
ure 2. In this example, the sending task sends a message 
to a mailbox and specifies a return mailbox. The send- 
ing task then waits at the return mailbox. The receiving 
task obtains the message from the sending mailbox and 
sends a message to the return mailbox. The first task 
obtains the second message from the return mailbox, 
synchronizing the two tasks and passing data. 


SENDING 
TASK 
4 


RETURN 
MAILBOX 


Figure 2. Intertask Communications with 
Mailboxes 


If process synchronization is the only requirement, sem- 
aphores may be used. Semaphores function like mail- 
boxes except that no data is passed through the sema- 
phore. Instead, semaphores contain ‘‘units,’’ with the 
meaning of the units defined by the sending and receiv- 
ing tasks. A one unit semaphore may be used as a flag to 
synchronize the tasks. Multiple unit semaphores can be 
used for resource control. For example, if tasks require 
reusable data buffers, a semaphore may be defined as 
the allocator of the available data buffers. Each unit in 
the semaphore will represent one available buffer. 
When a task requires buffers to continue, the task will 
wait at the semaphore until enough units (representing 
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buffers) are available. The waiting task will receive the 
units, use the buffers, and return the units (still 
representing buffers) to the semaphore. Other tasks that 
require buffers will also have to wait at the semaphore 
until enough buffers are available. 


Resource Management 


The operating system is the central guardian of system 
resources, specifically read/write memory. The memory 
is made known to the Nucleus at initialization. The 
Nucleus then gives pieces or segments of the memory to 
tasks as they request it. This allows the tasks to have no 
initial knowledge of the actual location and size of sys- 
tem memory. Tasks can share memory if they desire, 
but the Nucleus allocates memory to each task individ- 
ually, preventing the tasks from using each others mem- 
ory. In addition, tasks return memory to the Nucleus 
when they are through with it, allowing memory to be 
reused. 


Other system resources, such as I/O devices, will also be 
scheduled by the operating system. The operating sys- 
tem is responsible both for the efficient use of these 
resources and for providing the tasks with a large mea- 
sure of independence from the actual I/O hardware re- 
quirements. The system may require many types of I/O 
devices, such as disk drives, tape drives, and printers. 
I/O is more efficiently accomplished if the operating 
system provides both asynchronous and synchronous 
I/O operations. Synchronous operations are those the 
task starts and waits for completion, doing no other 
work until the I/O is complete. Asynchronous opera- 
tions are started by the task, but the actual I/O can take 
place while the task is doing other work. The overlapped 
operation of asynchronous I/O provides more user con- 
trol of the I/O operation at the expense of a more com- 
plicated user interface. 


Interrupt Management 


Real-time software is tightly coupled to hardware func- 
tions by interrupts. Interrupts provide rapid notification 
that the hardware needs attention. The software must 
respond quickly without corrupting the system environ- 
ment. System integrity is preserved by preempting the 
lower priority operating task, saving the task environ- 
ment, processing the interrupt (including communicat- 
ing the results to other tasks if necessary), restoring the 
environment of the operating task, and continuing. All 
of this must occur in an orderly and efficient manner. 
The interrupt management of the operating system is 
responsible for directly interacting with the system hard- 
ware that detects interrupts. The interrupt tasks can be 
ignorant of the detailed interrupt hardware, providing 
only the system actions to service the event that caused 
the interrupt. 
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Initialization 


Operating systems create aid manage jobs. and ee at 
initialization as well as run time. Initialization generally 
must be done in a specific sequence which will depend 
on the environment existing at that time. An abortive in- 
itialization environment may require an orderly shut- 
down of the system. Thé* operating system has the 
capability for managing | these situations, including com- 
munications, access to system resource information, 
and displaying status of the initialization actions. 


Debugging 


The system debugger i isa window into the internal struc- 
tures of the operating system. Debuggers allow data 
structures and memory to be examined, breakpoints to 
be set, and the user to be notified of abnormal condi- 
tions. The debugger may have symbolic debugging, in 
which system objects such as addresses, tasks, jobs, 
mailboxes, and memory locations can be assigned 
names. This gives greater flexibility and accuracy during 
debugging. The debugger may not be necessary in the 
final system, so the debugger is often a separate system 
job. This allows removal of the debugger with no le 
on the remaining jobs. | 


Debiigging will be aided if the operating system verifies 
the parameters required by system actions and also re- 
turns status for the requested action. Parameter verifi- 
cation is particularly valuable for new program code in 


a developing system. Status results other than success 


are abnormal or exception conditions. Exception condi- 
tions may include insufficient memory for: the request, 
invalid input data, inoperative I/O devices, an invalid 
request for an action, or a request for an invalid action. 
The operating system may have an exception handler 
for these conditions and may allow the debugger to be 
used as the exception handler. The development process 
will be more efficient if detection of exception condi- 
tions takes place for all levels of system actions, from 
initialization of jobs and tasks to requests for memory 
or status. 


Higher Level Functions | 


With the continuing increase in system complexity, 


more operating systems are providing higher level func- 


tions. These functions may include advanced I/O file 
management, operator console, spooling operations, 
telecommunications support, multiuser support and ac- 


cess to system resources of increasing size and complex-. 


ity. Only. the largest operating systems provide all of 


these capabilities, but users of component hardware 
must be. careful their system will integrate higher level. 


functions that may be required in future applications. 


In order to provide general purpose support, operating 
systems must be extendible. New applications may re- 
quire data structures or system actions not available 
with the present operating system. The system must be 
able to integrate these new structures and actions, sup- 
porting them in the same manner as existing functions. 
Choosing an operating system requires a large commit- 
ment, both in initial expense and system architecture. 
Extendibility provides assurance the operating system 
chosen will not provide built-in obsolescence of that 
commitment. 


iRMX ge™ OPERATING SYSTEM 
ARCHITECTURE ~ 


Layers 


The iRMX 86 Operating System architecture is shown in 
Figure 3. It includes the Nucleus, Basic I/O System, Ex- 
tended I/O System, Applications Loader, and Human 
Interface. These major portions of the operating system 
are designed as layers. Each layer may be added to 
previous layers as application needs grow. Lower layers 
may be used without upper layers. All layers may reside 
in programmable read only memory. Applications have 
access to all portions of the system, from the Nucleus to 
all outer layers. 


HUMAN INTERFACE 
"EXTENDED I/O =e 


USER APPLICATIONS 


Figure 3. Architecture of the iIRMX 86™ 
_ Operating System: 


The Nucleus is the heart of the system. It includes sup- 
port for multiprogramming, multitasking, communica- 
tions, synchronization, scheduling, resource manage- 
ment, extendibility, interrupt handling, and error detec- 
tion. The Nucleus may be considered as an extended 
layer of the underlying hardware, giving the hardware. 
system management functions and making the software 
independent: of the detailed hardware. The system en- 
vironment, including Tesources, priorities, and place- 
ment:of program code, is made known to the Nucleus at 
system initialization. All requests for memory, com- 
munication, and creation of basic data structures must 
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go through the Nucleus. These requests are made by 
system calls, which are comparable to subroutine calls 
for system actions. 


All higher level functions of the iRMX 86 Operating 
System are built around a core of the Nucleus. Although 
outer layers may require a substantial number of the 
system functions included in the Nucleus, the Nucleus 
itself is configurable on a call-by-call basis. ‘‘Configu- 
rable’’ means the Nucleus may be altered so it contains 
code only for those functions required by the applica- 
tion. Certain features, such as parameter validation and 
exception handling, are also configurable. Features and 
system calls may be included for development and ex- 
cluded from the final system, giving a Nucleus tailored 
for each level of application development. 


The Basic I/O System is the first layer above the 
Nucleus. The Basic I/O System provides asynchronous 
I/O support and format independent manipulation of 
data. Multiple file types are supported, including 
Stream, Named, and Physical files. Stream files are in- 
ternal files for transferring large amounts of data be- 
tween jobs or tasks. Named files include data files of 
varying sizes and directories for those files. Named files 
are designed for random access disk storage. Physical 
files consider the entire device to be one file. Physical 
files are primarily used to transfer data to and from 
printers, tape drivers, and terminals. Device drivers for 
both floppy and hard disks are provided. Like the 
Nucleus, the Basic I/O System provides system calls to 
invoke I/O actions. These calls and the features of the 
Basic I/O System are fully configurable. 


The Application Loader provides the ability to load 
code and data from mass storage devices into system 
RAM memory. The Application Loader resides on the 
Basic I/O System, allowing application code to be 
loaded from any random access device supported by the 
Basic I/O System. Application code can be loaded and 
executed as needed rather than residing in dedicated 
system memory. . 


The Extended I/O System supports synchronous I/O, 
automatic buffering, and logical names. Synchronous 
I/O provides a simplified user interface for I/O actions. 
Automatic buffering improves I/O efficiency by over- 
lapping I/O and application operations wherever possi- 
ble. Logical name support allows applications to access 
files with a user-selected name, aiding I/O device inde- 
pendence. 5 7 


The Human Interface uses all lower layers, forming a 
high level man-machine interface for user program in- 
vocation, command parsing, and file utilities. The 
primary purpose of the Human Interface is to support 
the addition of interactive commands. The Human In- 
terface is the basis for pass-through language support 
and multiple user systems. 


Configurability 


Configurability means the iRMX 86 Operating System 
can be changed to include only the system calls and 
features pertinent to the system under development. 
Smaller applications start with only the iRMX 86 
Nucleus. A subset of Nucleus calls, described later in 
this application note, provide the basis for management 
of jobs, tasks, memory, interrupts, communication and 
synchronization, and support for the Debugger and Ter- 
minal Handler. 


All systems calls may also use parameter validation as a 
configuration option. Parameter validation verifies that 
system calls reference correct system objects before the 
requested action is performed. During debugging and in 
hostile environments, validation provides error detec- 
tion for each system call. This error detection does add 


some overhead to the calls. Debugged application jobs 


can perform more efficiently without the validation, 
while new code can use parameter validation to speed 
development. 


Once errors are detected, there are two means available 
to handle error recovery. The task can either use the 
status information to perform error recovery actions or 
the recovery actions may be performed by a specialized 
error handling program called an exception handler. 
Applications may use the Debugger as an exception 
handler, or use one implemented by the application. 
There are two classes of errors that may cause control to 
be given to an exception handler; avoidable errors, such 
as programmer errors, and unavoidable errors, such as 
insufficient memory. Exception handlers can be selected 
to receive control for either or both classes. 


Support Functions 


The iRMX 86 Operating System includes a Debugger, a 
Terminal Handler, a Bootstrap Loader, and a Patch 
Facility. The Debugger examines system objects, using 
execution and exchange (mailbox and semaphore) 
breakpoints, symbolic debugging, and exception han- 


‘dling. The Terminal Handler provides a line-editing, 


mailbox-driven CRT communications capability. The 
Bootstrap Loader is a fully configurable loader for 
bootstrap loading on reset or command, from any spe- 
cific random access device. The Patch Facility gives the 
capability of patching iRMX 86 Object Code in the 
field. 


Object Orientation 


The iRMX 86 Operating System is based on a set of sys- 
tem data structures called objects. These objects include 
jobs, tasks, mailboxes, semaphores, segments, and 
regions. Users may also define application-specific ob- 
jects. Object architecture includes the objects, their 
parameters, and the functions allowed with the objects. 


AFN-01931A 


intel 


Object orientation is a formal, hardware-independent 
definition of hardware-dependent system structures that 
are currently used by most applications. For example, 
without object orientation, memory is ‘reserved in ad- 
vance for system buffers. The application code knows 
buffer sizes and locations. If buffer requirements grow, 
requiring a new memory layout, much of the applica- 
tion code will change to accommodate the new buffer 
sizes and’ locations. Using object, orientation, the ap- 
plication requests a segment (buffer) of a particular size 


when the buffer is needed. The Nucleus allocates the. 


memory. and. returns a segment object to the applica- 
tion. If the application needs a larger buffer, it returns 
the old segment and requests a new one of a larger size. 
The application obtains more buffers by making re- 
quests for more segments. If the hardware changes, the 
iRMX 86.-Operating System is made aware of the 
changes. The application. code uses the same system 
calls to -request and return ' the segment objects 
regardless of the hardware configuration. 


Objects are provided for modular eaviouiments (jobs), 
application: code functions (tasks), communication 
(mailboxes), synchronization (semaphores), memory 
(segments), and mutual exclusion (regions). Objects are 
fundamentally a set of standard interfaces between ap- 
plication code and the iRMX 86 Operating System. The 
standard: tntertaces have three primary benefits: | 


1) First, paren provide structures, sich as tacks or seg: 
ments, that are common: to. all applications. The 
structures form the basis for a standard set of system 
calls that make the interface between the application 
and the operating system more consistent and easier 
to learn. These calls allow applications to create more 
objects (segments for buffers, for example), delete 
them, change them, and inspect them. Development 
engineers can use their knowledge of the objects on 
many applications, rather than just the one under 
development. The common objects allow a common 
system debugger to be used. The debugger will work 
for all applications, letting engineers concentrate 
their efforts on the application itself rather. than 

= designing and implementing custom debugging tools. 


2) Second, the standard characteristics of the object 
_ allow consistent error detection and. handling. Re- 
' quests to alter or use objects can be checked for 
validity before the Nucleus actually performs the re- 
quest. Errors can be classed as common to all objects 
or specific to certain objects, giving more. precise 
error information for effective error handling and 
faster debugging. | 


3) Third, the object freee will be preserved on fata 
releases of the iRMX 86 Operating System. Current 
application code can be split into independent 
modules. Future applications can use the modules for 
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~ common functions, preserving me investment in ap: 
~ plication‘software. eo. 3 


Task Scheduling : | 
The Nucleus controls task scheduling _ task: priority 


and task state. Task priority is specified when the task:is 
created. The priority can be altered dynamically. Tasks 


are classified into one of five classes: Running, Ready, 
Asleep, Suspended, or Asleep-Suspended.: Tasks that 
have not been created are considered to be non-existent. 
The State Transition Diagram is shown in Figure 4. 


NON-EXISTENT ——> 


SUSPENDED 


| ASLEEP | 


ASLEEP. — 
SUSPENDED 


Figure 4. State Transition Diagram — 


Only one task is in the Running state. This task has con- 
trol of the central processor. The Ready state is occu- 
pied by those tasks that are ready to run but have lower 
priority than the Running task. The Asleep state is occu- 
pied by tasks waiting for a message, semaphore units, 
availability of a requested resource, an interrupt, or for 
a requested amount of time to. elapse. A task can specify 
the amount of time it will allow itself to spend i in the 
psleep state, but tasks in the Suspended state must be 

‘*resumed”’ by other tasks. The Suspended state is use- 
ful when situations require firm scheduling beyond the 
control provided by priority and system resource avail- 
ability. Examples of these situations are system emer- 
gencies, controlling tasks:in the Ready state for applica- 
tion-dependent scheduling algorithms, and guarantee- 
ing a fixed initialization or shut-down sequence. If 
another task “‘suspends’’ a task already in the Asleep 
state, the sleeping task goes to the. Asleep-Suspended 
state.: This task will enter the Suspended state if the 
sleep-causing condition is satisfied.. The task will go to 
the Asleep state from the Asleep-Suspended state if it is 
resumed before the sleep-causing condition is removed. 
If a task enters the Ready state and has higher priority 
than the present ‘Running task, the Ready task is given 
control of the CPU. Control iS transferred to another 
task only when: . 


1) The Running: task wiiakes a. pequest! that cannot im- 
mediately be filled. The Running task is moved to the 
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Asleep state. The highest-priority Ready task be- 
comes the Running task. 


2) An interrupt occurs, causing a higher-priority task to 
become Ready. The current Running task goes to the 
Ready state, allowing the higher-priority task to 
become the Running task. 


3) The Running task causes a higher-priority task to 
become Ready by releasing the resource for which the 
higher-priority task is waiting. The current Running 
task goes to the Ready state. The higher-priority task 

. becomes the Running task. 


4) The Running task causes a higher-priority task to 
become Ready by sending a message or semaphore 
units to the mailbox or semaphore where the higher- 
priority task is waiting. The Running task is moved 
to the Ready state. The higher-priority task becomes 
the new Running task. 


5) The Running task removes a higher-priority task 
from the Suspended state by ‘‘resuming”’ it, placing 
the higher-priority task in the Ready state. The cur- 
rent Running task is moved to the Ready state and 
the higher-priority Ready task becomes the new Run- 
ning task. 


6) The Running task creates a higher-priority task. The 
new task goes to the Ready state. The current Run- 
ning task is moved to the Ready state and the higher- 
priority Ready task becomes the new Running task. 


7) The Running task places itself in the Suspended state. 
The highest-priority Ready task becomes the new 
Running task. 


8) The Running task places itself in the Asleep state. 
The highest-priority Ready task becomes the new 
Running Task. 


9) The Running task deletes itself, becoming Non- 
existent. The highest-priority Ready task will be the 
new Running task. 


System Hardware Requirements. 


The iRMX 86 Operating System will run on any system 
that meets the following minimum hardware require- 
ments: 


1) An iAPX 86 or iAPX 88 Central pestetingt Unit. 


2) An Intel 8253 eee Interval Timer to Bre: | 


vide the system clock. 


3) An Intel 8259A Programmable Interrupt Controller. 


4) Enough hardware to provide a system clock and bus 


‘interfaces. This may be supplied by the Intel 8284 


Clock Generator, Intel 8288 Bus Controller, Intel | 
8282/8283 Latches, and Intel 8286/8287 Transceiv- 


ers. 
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5) The following RAM: 


a. 1024 bytes from 0 to 1024 for software interrupt 
pointers (the interrupt vector). 


b. 800 bytes for Nucleus data. 


c. Enough RAM for the application data, code, and 
system objects. 


6) Enough EPROM or RAM to hold the required parts 
of the iRMX 86 Operating System and the appHce 
tion code. 


The Intel iSBC 86/12A Single Board Computer more 
than meets these minimum requirements. A block dia- 
gram of the board is shown in Figure 5. Note in addition 
to the timer and interrupt controller the board contains 
an 8251A USART, an 8255 parallel I/O interface, a 
MULTIBUS™ interface, four sockets for up to 16K 
bytes of EPROM, and 32K bytes of dual-ported RAM. 
Even though a user may be developing a custom board 
for his application, it is recommended that initial system 
development be accomplished. using the iSBC 86/12A 
Single Board Computer. This will provide a known 
hardware environment to simplify debugging. In addi- 
tion, the development hardware system can be adapted 
to changing application needs by adding Intel MULTI- 
BUS compatible boards to the iSBC 86/12A Single 
Board Computer. After the software is fully debugged, 
the application can be moved to the final custom hard- 


_ ware design. 


APPLICATION EXAMPLE 


A spectrum analyzer is the subject of this application. 
The analyzer displays the frequency spectrum of an 
analog signal on a general purpose CRT terminal. The 
user has control over input signal bandwidth, averaging, 
and continuous analysis. A fast Fourier transform 
(FFT) program is used to obtain frequency data from 
samples of analog data. Fourier transforms provide use- 
ful frequency analysis, but the large processing require- 
ments of Fourier transforms have restricted their use. 
Fast Fourier transforms take advantage of the repetitive 
nature of the Fourier calculations, allowing the Fourier 
transforms to be completed significantly faster. The 
FFT used in this application note is known as ‘“‘time de- 
composition with input bit reversal.’’! Sixteen-bit inte- 
ger samples of the input signal are placed in frames, 
with each frame holding 128 complex points. An aver- 
aged power spectrum is calculated to sum and square 
the FFT values, yielding 64 32-bit power spectrum 
values. These values are displayed on a standard CRT 
terminal. | 


1. S. O. Stearns, Digital Signal Analysis, Hayden Book Co., Rochelle 
Park, NJ, 1975. 
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Figure 5. iSBC 86/12A™ Single Board Computer Block Diagram 


The FFT algorithm may be applied wherever frequency 
analysis of an analog signal is required. Medical appli- 
cations for FFTs include EEG analysis, blood flow 
analysis, and analysis of other low-frequency body sig- 
nals. Industrial uses are production line testing, wear 
analysis, frequency signature monitoring, analysis in 
noisy or hostile environments, and vibration analysis. 
Other applications could cover remote reduction of 
analog data, frequency correlation, and process control. 
For this application note, the actual use of the FFT is 
secondary to its existence as a modular, CPU-intensive 
task in a general purpose sent: : : 


The overall application system characteristics are the 


following: 


1) A user-selectable input signal bandwidth of 120 Hz, 
600 Hz, 1200 Hz, 6000 Hz, or 12,000 Hz. 


2) The option of averaging frames of samples. The 
averaging is user selectable, with options of 1 (no 
averaging), 2, 4, 8, 16, or 32 frames averaace per 
CRT display. . 


3 )The capability, also user selectable, of repeating the 
analysis cycle continuously. ” 


4) User capability to abort the analysis. 
5) Twelve-bit input sample resolution. 


6) A minimum of hardware requirements, including no 
more than 32K bytes of EPROM memory and 16K 
bytes of RAM memory. 


7) A standard character screen CRT for output. 


8) A multitasking structured design that will use a 
subset of the iRMX 86 Nucleus and exhibit modular 
application code, formal interfaces, and self- 
documentation. oo 


Sveti Design 

To begin the design, the application is broken up into 
functional modules, much the same as a hardware block . 
diagram. A SUPERVISOR TASK initializes the system, — 
accepts operator parameters, starts the analysis cycle, 
and stops the processing upon cycle completion or 
operator request. An INPUT TASK samples the data 
and places it in a buffer. An FFT TASK receives the 
buffer and processes the data. An OUTPUT TASK dis- 
plays the data received from the FFT TASK. This struc- 
ture is shown in Figure 6. | 
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Figure 6. Basic Application Architecture 


The general task functions are: 


SUPERVISOR TASK: The SUPERVISOR TASK ini- 
tializes the system by creating the other tasks. The 
SUPERVISOR TASK then obtains the analysis param- 
eters from the operator. Each parameter is verified as it 
is received. When all of the parameters are accepted, the 
operator is asked if they are satisfactory. If the operator 
agrees, the SUPERVISOR TASK sends frame buffers 
to the INPUT TASK to initialize the analysis. If not, the 
operator is asked to input all of the parameters again. 
During the FFT analysis, the SUPERVISOR TASK 
waits for an abort request from the operator and for the 
frame buffer from the OUTPUT TASK. If the abort re- 
quest is received, the SUPERVISOR TASK terminates 
the analysis in an orderly fashion and asks the operator 
for parameters for the next analysis cycle. If the frame 
buffer is received from the OUTPUT TASK and con- 
tinuous analysis has been selected, the SUPERVISOR 
TASK sends the frame buffer to the INPUT TASK to 
start the next cycle. If the frame buffer is received from 
the OUTPUT TASK and continuous analysis has not 
been selected, the current analysis is complete and the 
SUPERVISOR TASK asks for new parameters. 


INPUT TASK: The INPUT TASK receives the frame 
buffer from the SUPERVISOR TASK. The input signal 
is sampled according to the analysis parameters. The 
actual sample rates are calculated as follows: 


1) Multiply the highest frequency of interest by two to | 


obtain the Nyquist sampling rate. 
2) Invert this value to obtain time between samples. 


3) Scale the value by 60/64. The CRT display is limited 
to 64 columns. The scaling maps sample values to 


columns 1 to 60 rather than 1 to 64, giving a more. 


readable x-axis label and display. This method yields 


sample times of 3.9 milliseconds, 781 microseconds, | 


390 microseconds, 78 microseconds, and 39 micro- 
seconds for frequencies of 120 Hz, 600 Hz, 1200 Hz, 
6000 Hz, and 12,000 Hz. 


The INPUT TASK samples the data at the ee 
interval and places the samples in the frame buffer. 


When the frame buffer is full, the INPUT TASK up- 


dates the frame buffer. number and sends the frame buf- 
fer to the FFT TASK. The INPUT TASK sends a status 
message to the CRT terminal and waits for the next : 
frame buffer. 


FFT TASK: The FFT TASK receives the frame buffer 
from the INPUT TASK. A fast Fourier transform is 
performed on the data contained in the buffer, the 
power spectrum is calculated, and the data is averaged 
with previous data if necessary. If the frame buffer is 
the last one to be averaged prior to display of the fre- 
quency data, the frame buffer is filled with the averaged 
data and sent to the OUTPUT TASK. If the buffer is 
not the last one to be averaged, the FFT TASK returns 
the buffer to the INPUT TASK for another frame of 
data or to the SUPERVISOR TASK if the analysis cycle 
is nearly complete. The FFT TASK sends status infor- 
mation to the CRT display and waits for the next frame 
buffer from the INPUT TASK. | | 


OUTPUT TASK: The OUTPUT TASK receives the 
frame buffer from the FFT TASK. The data is format- 
ted and displayed. The OUTPUT TASK sends the 
frame buffer to the SUPERVISOR TASK and waits for 
the next frame buffer from the FFT TASK. 


Terminal Handler: The Terminal Handler serves as the 
basic I/O device for parameter requests, status data, © 
and frequency displays. The Terminal Handler accepts 
display requests from all tasks and sends operator input 
to the SUPERVISOR TASK. 


The basic functions of the various tasks in the applica-. 
tion have been defined, but system integration has not 
been discussed. Synchronization of the tasks, schedul- 
ing, resource management, mapping to hardware, inter- 
rupt handling, and system interfaces have been omitted. 
No debugging functions have been defined. It is clear 
the system implementation is just started. The iRMX 86 
Nucleus will provide all of the system integration 
‘*slue’’ the application requires, allowing application 
programmers to concentrate on the actual functional 
code. In order to use this ‘‘glue,”’ the application must 
be divided into jobs and ee 


Jobs and Tasks 


The iRMX 86 Operating System architecture defines 
jobs as separate environments within which tasks oper- 
ate. These separate environments allow each job to 
function with no knowledge of other system jobs. There 
are two jobs in this application, the Debugger job and 
the Application job. 


The jobs contain functional portions or Satine pro- 
grams called tasks. The Application job contains the 
INIT TASK, SUPERVISOR TASK, INPUT TASK, 
FFT TASK, OUTPUT TASK, and INTERRUPT 
TASK. The Debugger job contains the Debugger task 
and the Terminal Handler task. Tasks provide the ap- 
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plication goals of modularity, resource constraint boun- 


daries, and functional independence. The structure of: 


the development system is.shown in Figure 7. 
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TASK SUPER- | OUTPUT 
VISOR aren 
TASK . 
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INTERRUPT FFT 
TASK ; TASK © TASK 


DEBUGGER 
JOB 


APPLICATION 
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Figure 7. Development System Job Structure 


The Debugger job is included only for development. 
When development is completed, the Debugger job is 
removed from the system. A Terminal Handler job con- 
taining only the Terminal Handler task is substituted in 
place of the Debugger job. The application code is not 
changed. This structure is shown in Figure 8. 


INPUT Suison | output 
TASK Gaee TASK 
INTERRUPT FFT 
TASK TASK 


APPLICATION 
JOB. 


TERMINAL 
HANDLER 
TASK 
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Figure 8. Final System Job Structure | 


Interfaces and Synchronization 


Now that the system is made of jobs and tasks, the 
primary need is to synchronize the tasks and provide 
communication interfaces. This will be handled by mail- 
boxes. The messages sent via the mailboxes will be seg- 
ments, which are pieces of memory allocated by the 
Nucleus. The frame buffers sent from task to task are 
these segments. The buffer segments contain all the 
analysis parameters in addition to the data samples. 
Communication with the Terminal Handler task is also 
accomplished by mailboxes, but with a different buffer 
format. The Terminal Handler format has fields for the 


operation requested (read or write), the number of 


characters the task wishes to read or write, the number 
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of characters the Terminal Handler did read or write, a 
status field for the operation, and the actual data. The 
buffer format is shown in Figure 9. Figure 12 contains 
the Terminal Handler segment format. 7 


BEGINNING OF 


SEGMENT 


NUMBER SAMPLES MISSED 
SAMPLE POINTER 
RESET FLAG 
DATA SAMPLES 
DATA SAMPLES 


Figure 9. Frame Buffer Format 


Mailboxes are used to pass the buffer segment from task 
to task. Tasks can send segments to mailboxes, or 
receive segments from mailboxes. If there is no segment 
at a mailbox, a task can elect to wait for the segment, 
with the wait duration ranging from zero to forever. 
This provides the simplest system synchronization — 
each task, upon initialization, waits at its input mailbox 
for a frame buffer segment. When the task receives the 
segment, it processes the data, sends the segment on to 
the mailbox for the next task, and returns to its own 
mailbox to wait for the next frame buffer. The system is 
synchronized and controlled by the availability of frame 
buffers and task priority. It should be clear that multi- 
ple frame buffers segments provide overlapped process- 
ing, with the segments ultimately ‘‘piling up’’ at the 
slowest task in the chain. This loose coupling arrange-. 
ment allows tasks to have radically different execution . 
times. For example, the INPUT TASK has an input 
sampling time that ranges from 0.6 seconds to 6.3 milli- 
seconds, a range of 100 to 1, and the system requires no 
special synchronization or scheduling to accommodate 
this range. 


The mailbox interfaces, shown in Figure 10, serve 
several other important purposes. First, they provide 
the standardized interface that is a goal of this applica- 
tion. The set of mailboxes and the two buffer segments 
form all inter-task interfaces. Each task uses only a few 
mailboxes, making it easy to add or remove tasks by 
adding or removing mailboxes. The system could easily 
be expanded to include data reduction tasks, data cor- 
relation tasks, or to substitute different tasks for any of 
the present ones. Dummy tasks were used for real tasks 
during development to verify overall system execution 
before the actual tasks were available. 
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Figure 10. Application Architecture with 
Mailboxes. 


The mailboxes also provide a very convenient window 
into the application system processing for both debugg- 
ing and aborting the current cycle. The Debugger can set 
breakpoints at mailboxes to allow users to examine the 
frame buffers as they progress from task to task. The 
Debugger can examine buffer data and control the pro- 
cessing cycle. Tasks wait at the mailboxes in a queue 
that is either priority or first-in-first-out (FIFO) based. 
The inter-task mailbox queues are priority based, which 
means the higher priority SUPERVISOR TASK can in- 
tercept segments at the mailboxes ahead of the lower 
priority waiting tasks, and abort the analysis by remov- 
ing all of the buffer segments. This method of aborting 
requires no knowledge of the internal processing of the 
tasks, making it universally applicable to all the tasks. 


A return mailbox may be specified when a segment is 
sent to a mailbox. The receiving task may send status in- 
formation, a different segment, or the original segment 
to the return mailbox. The Terminal Handler will return 


# 
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2000 3000 - 


Current settings are the following: 
16 frames to average per output display, and continuous runs. 


The INPUT TASK has processed 16 frames out of 16 frames to average. 
The FFT TASK has processed 16 frames out of 16 frames to average. 


# 
# 
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the buffer segment sent to it if a return mailbox is 
specified. This is used to synchronize the tasks with the 
Terminal Handler and to allow multiple tasks to use a 
single display task. Each sending task waits at a separate 
return mailbox for the Terminal Handler to return its 
segment. Each task retains control over its buffer seg- 
ment and is synchronized with the slower data display 
function. 


Priority 


In addition to the mailboxes, task execution is governed 
by priority. In this system, the INPUT TASK has maxi- 
mum priority to guarantee it can sample the input signal 
at the precise intervals required for the FFT. The 
SUPERVISOR TASK, responsible for abort functions, 
has the next level of priority, with the FFT TASK next, 
and the OUTPUT TASK lowest. 


APPLICATION IMPLEMENTATION 


Display Functions 


All application tasks use the iRMX 86 Terminal Han- 
dler as an output device. The Terminal Handler is 
chosen because it provides a standard interface consis- 
tent with the application goals, it exists both in the De- 
bugger job and in an independent job, and it is easy to 
integrate into the application system. The application 
could also use the same interface with a user-written 
Terminal Handler. In this application, the Terminal 
Handler can have messages from four tasks on the 
screen at one time. To allow this to occur in an orderly 
fashion, lines on the screens are reserved for each of the 
tasks. The screen format is shown in Figure 11. Each 
message to the screen sends the cursor to the upper left 
corner (the home position), then down to the proper line 
to display the data. 
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Figure 11. CRT Screen Display Format 
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Cataloging 


To aid the debugging process, all system objects, such as 
mailboxes, segments, and tasks, are cataloged in the 
directory of the SUPERVISOR TASK. The catalog en- 
tries are user-selected, 12-character names. The Debug- 
ger can display this directory, giving easy access to ob- 
jects to aid symbolic debugging. If other tasks know the 
proper directory and the 12-character name, the tasks 
can look up the objects in the directory and obtain ac- 
cess to them. This is the method used to find the Ter- 
minal Handler mailboxes. For objects that are cataloged 
only to aid debugging, the system calls that catalog the 
objects are removed from the code when debugging is 
complete. 


Application Code 


The code listings for the SUPERVISOR TASK and the 
INPUT TASK are included in appendices to this note. 
Code listings for other tasks are not included, but they 
are available from the Intel Insite software library. The 
following discussions reference line numbers in the list- 
ings included in this note. The references begin with a 
first letter for the appendix section (A or B), followed 
by the actual line number (A.220, for example). 


SUPERVISOR TASK 


Code listings for the SUPERVISOR TASK are in Ap- 
pendix A. The actual SUPERVISOR TASK procedure 
begins at line A.550. After initializing internal buffers 
and mailboxes (A.551, A.518-A.549), the Supervisor 
sends an initial screen, one line at a time, to the Termi- 
nal Handler (A.553, A.502-A.517). When the screen is 
complete, the SUPERVISOR TASK creates the INPUT 
TASK, FFT TASK, and OUTPUT TASK (A.554, 
A.486-A501). The order of creation is not important 


for this application, as each task begins by waiting at its . 


input mailbox for frame buffer segments. The SUPER- 
VISOR TASK requests input parameters from the oper- 
ator (A.556, A.305-A.485). The actual input parameter 
loop is found at A.478. The loop consists of asking 
questions (A.479, A.480) until all answers are satisfac- 
tory. The operator is asked to choose the highest fre- 
quency of interest, number of frames to average, and 
single runs or continuous runs (A.331-A.353). If the 
operator answers with an invalid input, the question is 
repeated (A.365 and A.415). If the operator wishes to 


abort the questioning by entering a 99, the questions . 


start over from the first question (A.409-A.413). When 
all three questions have been answered, the operator is 
asked to confirm his choice (A.482, A.418-A.467). If 


the operator does not verify the answers, the question — 
number is set to 0 (A.463) and the parameters are re-. 


quested again. If he confirms the answers as correct, the 
SUPERVISOR TASK creates up to three frame buffer 
segments (A.557, A.279-A.304). The. SUPERVISOR 


TASK places the binary equivalents of the operator. 
answers in the frame segments (A.284, A.292, A.300, 
A.269-A.278), and sends the segments to the input 
mailbox for the INPUT TASK (A.287, A.294, A.302). 


The SUPERVISOR TASK’s background duties are to 
check its input mailbox for a segment from the OUT- 
PUT TASK and to check a return mailbox for an abort 
request from the operator (A.558, A.225-A.268). If 
segments are received at the SUPERVISOR TASK mail- 
box, the SUPERVISOR TASK sends the segments on to 
the INPUT TASK if the operator has chosen continuous. 
runs (A.258). Otherwise, the SUPERVISOR TASK de- 
letes the segments (A.242-A.250). When all the 
segments have been deleted, which halts the FFT 
analysis, the SUPERVISOR TASK asks for operator in- 
put again (A.556). 


If an operator abort request is received, the SUPER- 
VISOR TASK, having higher priority than the FFT or 
OUTPUT TASKS, waits at their mailboxes to intercept 
the frame segments (A.243, A.249, A.207-A.224). 
When a segment is received it is deleted (A.219). The 
SUPERVISOR TASK also checks the INPUT TASK 
mailbox under abort conditions (A.244). This mailbox. 
is FIFO based to allow the SUPERVISOR TASK to in- 
tercept the buffer segment ahead of the higher-priority 
INPUT TASK (A.523). The SUPERVISOR TASK in- 
put mailbox is also checked for frame buffer segments 
that may have been sent there by the OUTPUT TASK 
after the abort was requested (A.246). When all of the. 
frame buffer segments have been deleted, the SUPER- 
VISOR TASK asks for operator input (A.556). 


INPUT TASK 


Listings of the INPUT TASK are in Appendix B. After 
initializing the buffer for Terminal Handler communi- 
cations and the mailboxes for communicating with the 
INTERRUPT TASK and the Terminal Handler (B.335, 
B.302-B.333), the INPUT TASK waits at its input mail- 
box for a frame buffer segment (B.338). 


When a frame segment is received, the INPUT TASK 
updates the frame number counter kept by the INPUT 
TASK (B.340, B.289-B.301), and samples the analog in- 
put (B.341, B.231-B.288). The INPUT TASK selects 
one of two input driver routines, either a software poll- 
ing loop for faster sampling rates (B.277-B.281), or an 


INTERRUPT TASK for slower sampling rates 


(B.251-B.276). If the sampling is driven by interrupts © 
and a Nucleus system call is executing at the time of the 
interrupt, the time required to respond to that interrupt . 
can vary from 100 to 350 microseconds, depending on 
the Nucleus call in progress. For the sample rates of 391, 


_- 78, and 39 microseconds, corresponding to bandwidths 
of 1200, 6000, and 12,000 Hz, the system interrupt 


latency cannot guarantee the precise sampling interval 
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required. A a simple software polling loop with a delay 
between samples is used for these rates (assembler code 
for this loop is included after the INPUT TASK listings 
in Appendix B). This loop operates at priority 0, the 
highest priority, to guarantee the loop is not interrupted 
(B.278, B.280) while the sampling is in progress. 


For the longer intervals of 3.9 milliseconds and 781 
microseconds, corresponding to bandwidths of 120 and 
600 Hz, an Interrupt Handler and and INTERRUPT 
TASK are used (B.251-B.276). Under the iRMX 86 
Operating System architecture, an Interrupt Handler is 
defined as a short procedure with a primary goal of fast 
interrupt response and limited Nucleus calls. All hard- 
ware interrupt levels are masked when an Interrupt 
Handler is responding to an interrupt. If the interrupt 
servicing requires higher-level system functions, the In- 
terrupt Handler notifies a waiting INTERRUPT TASK. 
Higher-level interrupts are enabled when an INTER- 
RUPT TASK is executing. INTERRUPT TASKS can 
make all system calls. 


The INTERRUPT TASK (B.196-B.203) binds the In- 
terrupt Handler to the hardware interrupt level (B.197) 
and waits for a signal from the Interrupt Handler 
(B.199). The Interrupt Handler (B.164-B.195) verifies 
the interval accuracy (B.166-B.173), samples the data 
(which automatically starts the next sample) (B.175- 
B.176), places the data in the frame buffer (B.181- 
B.184), and notifies the INTERRUPT TASK when the 
frame buffer is full (B.193). If the buffer is not full, the 
Interrupt Handler resets the interrupt hardware (B.194). 
The INTERRUPT TASK notifies the INPUT TASK 
(B.200) and waits for a return message (B.201). The IN- 
PUT TASK disables interrupt level 3 (B.274) and re- 
turns the token to the INTERRUPT TASK (B.275). The 
INTERRUPT TASK enables the Interrupt Handler 
(B.199), but no interrupts will be received from the free- 
running 8253 Timer because hardware interrupt level 3 
has been disabled. Sampling for the next buffer is in- 
itiated by simply enabling level 3 (B.272). The INPUT 
TASK sends a status message to the Terminal Handler 
(B.342, B.219-B.230) and sends the filled frame buffer 
to the FFT TASK (B.343). The INPUT TASK then 
returns to the INPUT TASK input mailbox to wait for 
the next frame segment (B.338). 


FFT TASK 


Listings for the FFT TASK are not included with this 
application note. The FFT TASK is similar in overall 
format to the INPUT TASK. The FFT TASK waits at 
its input mailbox for a frame buffer segment from the 
INPUT TASK. When one is received, the FFT TASK 
computes the fast Fourier transform of the data. The 
auto power spectrum is computed and averaged with 
previous data. The FFT TASK sends its status message 
to the Terminal Handler for display. If the frame buffer 
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is the final one to be averaged, the FFT TASK sends the 
frame buffer to the OUTPUT TASK. If the frame buf- 
fer is not the final one in this averaging series, the FFT 
TASK checks to see if the sampling process is continu- 
ous. If so, the frame buffer is returned to the INPUT 
TASK. If the sampling process is not continuous and 
the buffer is within two frames of the final frame buf- 
fer, the buffer is returned to the SUPERVISOR TASK 
to prevent unnecessary buffers from going to the IN- 
PUT TASK. The FFT TASK then returns to its input 
mailbox to wait for the next frame buffer. 


- OUTPUT TASK 


Listings for the OUTPUT TASK are not included in this 
application note. The OUTPUT TASK, like the other 
tasks, waits at its input mailbox for a buffer. When a 
frame buffer is received from the FFT TASK, the OUT- 
PUT TASK stores the data in an internal buffer and 
sends the frame buffer to the SUPERVISOR TASK. 


The OUTPUT TASK converts each 32-bit frame buffer 
value to one of 16 levels by taking the base 2 logarithm 
of the significant 16 bits of sample value. The display 
screen is sent to the Terminal Handler one line at a time. 
Each line of the display is composed of 7 characters of 
label and y-axis data and 64 characters of display data 
(reference Figure 11). Each line of the display represents 
a power of two (from 16 down to 1). The character to be 
displayed at each location is found by comparing the ap- 
propriate sample value against the current line value. If 
the sample value is greater than the line number, a 
pound sign is displayed at that location. Otherwise, a 
space is displayed. The x-axis and labels are sent after 
the data lines to complete the display. The OUTPUT 
TASK then waits at its input mailbox for another frame 
buffer. 


TERMINAL HANDLER 


The Terminal Handler interfaces to the application 
tasks via the two mailboxes and buffer segment format. 
shown in Figure 12. If a task wishes to display data, a 
segment containing the data is sent to the RQ$TH$- 
NORMS$OUT mailbox, specifying a return mailbox. 
The Terminal Handler displays the data, updates the. 
status fields, and sends the segment to the return 
mailbox. 


Input proceeds in much the same fashion. A task 
requesting data sends a segment to the 


RQ$TH$SNORMSIN mailbox, again specifying a return. 


mailbox. When the operator terminates the input line 
with a carriage return, the Terminal Handler puts the - 
data in the segment, updates the status fields, and sends 
the segment to the return mailbox. This serves two 
primary purposes: specifying return mailboxes allows 
multiple tasks to share the display screen while retaining 
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Figure 12. Terminal Handler Interface 


synchronization and control over their data buffers; and 
a user-written Terminal Handler using the same pro- 
tocol and mailbox names could easily be integrated into 
the application. For this application, the INPUT TASK, 
FFT TASK, OUTPUT TASK, and SUPERVISOR 
TASK all share the screen for output, but only the 


SUPERVISOR TASK uses the Terminal Handler to ob-_ 


tain operator input. | ; 


Nucleus Calls 


The iRMX 86 Nucleus provides a comprehensive set of 
61 system calls. A complete description of these calls 
may be found in the iRMX 86 Nucleus Reference 
Manual. For most applications, only a subset of the 61 
calls will be required. The iRMX 86 Nucleus is configur- 
able, which means the final system Nucleus will contain 
code only for the system calls required for the applica- 
tion. In this case, the following system calls were 
required: | . 


RQ$CREATE$MAILBOX, RQ$SEND$MESSAGE, 


and RQ$RECEIVE$MESSAGE provide mailbox man- 
agement. mot 7 mo, | 
RQ$CREATE$SEGMENT and RQ$DELETES$SEG- 
MENT are used to create and delete segments for the 
frame buffers, internal buffers, and Terminal Handler. 


RQS$SETSINTERRUPT, RQ$EXITS$INTERRUPT, 
RQ$SIGNAL$INTERRUPT, RQS$WAITSINTER- 
RUPT, RQ$ENABLE, and RQ$DISABLE allow the 
INPUT TASK to handle hardware interrupts knowing 
only the hardware interrupt level (3). aa 


RQ$CREATES$JOB, RQ$CREATESTASK, and 
~RQS$SET$PRIORITY are used to create the jobs and 


tasks, and set the priority of the input polling loop. 


RQ$GET$TASK$TOKENS, RQ$LOOKUPS$OBJECT, | 


RQ$CATALOG$OBJECT, RQ$DISABLE$DELE- 
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PROVIDED 
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FUNCTION | 
(READ OR WRITE) 
COUNT 
__ (# CHARS. TO READ/WRITE) 
EXCEPTION CODE 
_ (STATUS) > = 
| ACTUAL. 
RESPONSE | (# CHARS. READ/WRITTEN) | 
DATA 


MAILBOX . 
SAMPLES 


TERMINAL 
HANDLER 


TION, RQ$ENABLE$DELETION, RQ$GETS$TYPE, 
RQ$GET$PRIORITY, RQ$GETS$SIZE, and RQ$SIG- 
NAL$EXCEPTION are system calls required by the 
Debugger and the Terminal Handler. None of these 
calls are necessary in this application if a user-written 
Terminal Handler is used and debugging is completed. 


System Configuration 


System Configuration is the integration step in the 
development process. It consists of selecting the por- 
tions of the iRMX 86 Operating System required in the 
application, mapping this code and the application code 
to system memory, and creating a Root Job that will in- 
itialize the system. The overall configuration process is 
shown in Figure 13. Configuration requires knowledge 
of available memory, operating system and application 
code entry points, priorities, exception handlers, and 
other system parameters. System Configuration consists _ 
of the following steps: 7 


1) Selecting the portions of the iRMX 86 Operating 
_ System required by the application, including. the 
layers. and the specific system calls in each layer. 


2) Linking and locating those portions. 


3) Assembling or compiling, linking, and locating the 
application code. | 


4) Creating a configuration file that will tell the Nucleus 
the locations of available RAM memory, initial char- 
acteristics of each system job, and pertinent overall 
system parameters. Each job in the system has an en- 
try in the configuration file. The order of the entries 
is the order of initialization of the jobs. | 


5) Creating the Root Job by assembling, linking, and 
locating the-configuration file. — — : 
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Figure 13. System Configuration Process 


During development of an EPROM-based application 
such as this one, configuration is accomplished twice: 
once for the RAM-based development system and once 
for the final EPROM-based system. These configura- 
tions are detailed in Appendix C, System Configura- 
tion. In both cases, the Root Job that results from con- 
figuration initializes the system jobs. For development, 
the system job structure is shown in Figure 7. The Root 
Job creates the Debugger Task in the Debugger Job, 
which in turn creates the Terminal Handler Task. The 
Root Job then creates the SUPERVISOR TASK, which 
creates the INPUT TASK, FFT TASK, and OUTPUT 
TASK. The INPUT TASK creates the INTERRUPT 
TASK when necessary. 


Software development is completed on the iSBC 86/12A 
Single Board Computer discussed earlier in this note. 
After application code is debugged and ready to be 
placed in EPROM memory, the Debugger Job, which 
contains both the Debugger and the Terminal Handler, 
is removed and replaced with the Terminal Handler 
Job, which contains only the Terminal Handler. This 
job structure is shown in Figure 8. The Nucleus system 
calls required only by the Debugger are removed from 
the iRMX 86 Nucleus. The application. code is not 
changed. The application code and the iRMX 86 
Nucleus is configured for the final system, put ‘in 
EPROM memory, and tested on the final hardware sys- 
tem. The final Nucleus and application code required 
30.5K bytes of EPROM, allowing room for future code 
‘changes and some papansion within he oe system 
limit. 


The final application hardware is shown in Figure 14. 
This system contains an iAPX 86/10 CPU, an 8259A 
Programmable Interrupt Controller, and an 8253 Pro- 


grammable Timer. The three chips form the primary 
hardware requirements for the iRMX 86 Operating Sys- 
tem. The system is assembled from Intel components, 
using standard support circuits and system schematics 


described in Intel documentation. The analog sampling 


circuitry is a 12-bit analog to digital converter (ADC) 
and a sample/hold circuit. Both the sample/hold circuit 
and the ADC are driven from the on-board local bus. 
The ADC has a conversion time of 35 microseconds, 
limiting the overall cycle to approximately 39 micro- 
seconds per sample, or a maximum CRT Eley band- 
width of 12,000 hz. 


The hardware system shown in Figure 14 contains com- 
ponents not specifically required for the final configura- 


tion. The 8255A Programmable Peripheral Interface 


and the MULTIBUS multimaster interface are not nec- 
essary for a system limited to just spectrum analysis and 
display via the CRT. However, the flexibility advan- 


tages of the iRMX 86 Operating System are supported 


by this hardware. For instance, the frequency spectrum 
display is limited by the CRT to a 16-level logarithmic 
approximation. Accuracy could be improved by using 
the programmable peripheral interface to drive a plotter 
or an analog CRT via a digital to analog converter. 
Software drivers for the plotter or CRT could be new 


_tasks, interfacing to the old tasks through the mail- 


boxes. Or, the OUTPUT TASK could be simply re-— 
placed with a new OUTPUT TASK for the plotter and 


analog CRT. The inclusion of the MULTIBUS interface, 


allows this application to be integrated into a larger 
system of MULTIBUS-compatible boards. MULTI- 
BUS-compatible memory boards will also aid test and 
debug. Users of hardware components can include these 
modular Intel interfaces as required by their applica- 
tion, giving growth and configurability in both hard- 
ware and software. | 
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SUMMARY — 


This application note discussed general operating sys- 
tem functions, the Intel iRMX 86 Operating System, 
using the iRMX 86 Operating System on hardware com- 
ponent systems, and an example of an application im- 
plemented in a component environment. Users of the 
iIRMX 86 Operating System are able to simplify applica- 
tion code development through modularity, standard 
— Interfaces, freedom from rigid hardware restrictions, 
and advanced debugging techniques. The iRMX 86 
‘Operating System can be applied to larger systems by 
adding other iRMX 86 layers, making the software in- 
vestment beneficial over a wide Tange of applications. 


Operating systems provide many advantages for hard- 
ware component designs, but all of these benefits can be 
utilized only if the operating system and the develop- 
ment environment are fully supported. Intel’s support 
for this application begins with an Intel MDS 230 Series 
‘II Microcomputer Development System. The MDS 230 
System interfaces with the development hardware 
through the iSBC 957A™ Monitor. The development 
hardware is an Intel iSBC 86/12A Single Board Com- 
puter, an Intel iSBC 71 1™ Analog Input Board, an Intel 
iSBC 032™ 32K RAM Memory Board, an Intel iSBC 

064™ 64K RAM Memory Board, and an Intel iSBC 

-660™ System Chassis. Final application hardware is de- 
bugged using Intel’s ICE- 86™ 8086 In-Circuit Emu- 
lator. Software support is provided by the ISIS- II 
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Figure 14. Final Hardware System Block Diagram 
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PL/M 86™ Compiler, MCS-86™ Macro Assembler, 
and the MCS-86 Utilities LINK86, LOC86, and OH86. 


The Intel UPP-103™ Universal PROM Programmer is 


used to convert the final system to PROM memory. 
This broad support allows expedient development of 
prototype and final systems based on the iRMX 86 
Operating System. 


The iRMX 86 Operating Systems and the Intel develop- 
ment tools are valuable only if they translate directly to 
increased productivity and shortened time to market for 
new products. This application has 1567 lines of appli- 
cation code. It was developed, from design to final im- 
plementation, in approximately 9 man-weeks of effort. 


This high level of productivity was achieved with the 
added benefits of modularity, standardization, and ease 
of application growth. 


Intel Corporation is committed to both the continued 
integration of higher-level functions into hardware and 


-to maintaining compatibility of present software with 


new hardware. One result of these commitments will be 
the Intel iAPX 86 and:iAPX 286 Processors, which will 
be compatible with the iRMX 86 Operating System. 
Another result will be the placement. of the iRMX 86 


Operating System Nucleus into hardware. This will 


allow custom hardware applications to have higher-level 
functions, simplified development, and decreased chip 
count. Using the iRMX 86 Operating System today will 
give hardware component users a headstart on Intel’s 
technological innovation for tomorrow. . 
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PL/M-86 COMPILER SUPERVISOR TASK FOR AP NOTE 110, OCTOBER 1980 
ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE SUPERVISOR _ MODULE 


OBJECT MODULE PLACED IN 
COMPILER INVOKED BY: 


089 


a 


he 


ee 


:Fl:ssuperv.OBJ 
plm86 :Fl:Superv.p84 


Stitle(' SUPERVISOR TASK FOR AP NOTE 110, OCTOBER 1980') 
Slarge debug | 
SUPERVISOR MODULE: 


$include(:£1:nuclus.ext) 
SSAVE NOLIST 


declare token literally ‘word's: 


[PRR KEKRKERKERERKERRRRKEKRKEKKREKKRKEKKKKRKKRKREKK / 
/* The six mailboxes immediately following will */ 


declare 


parameters 
actual samples 


2-262 


structure ( 


word, 


/* form all of the inter-task communications * / 

/* interfaces for the five tasks that run in */ 

/* this system. a 

[J RRRREREREER KEKE REE REK RRR REKEE REE EER ERK EKKREKEK KK / 

declare th in mbx token; 

declare th out mbx token; 

declare to input mbx token public; 

declare to fft mbx token public; 

declare to output mbx token public; 

declare to supervisor mbx token public; 
declare return th in mbx © token; 

declare return th out _mbx token; 

declare dummy _ mbx — token; 

declare frame _segment one token; 

declare frame _segment _ two token; 

declare frame _segment _ “three token; 

declare th in segment token token; 

declare th out segment token token; 

declare general index byte; 

declare number of fft data_segments byte; 

declare insert text pointer pointer; 

declare abort flag word; 

declare status word; 

declare segment deleted tally word; 

declare text _length — word; 

declare root job token token; 

declare input task token token; 

declare fft task token token; 

declare output _task_token token; 
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117 
118 
Lo 
120 
2d 
122 
123 
124 
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128 
129 
130 
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134 


139 
140 


ee ee ee 


1 
il 


declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
declare 
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actual interval 
frequency answer (5) 
actual frames to _average 
frames to _average__ answer 
continuous _flag 


continuous | Flag answer (5 
abort 

ascii 9 

carriage return 

forever 


line feed 

new fft run 

no abort 

no response requested 
null 

queue fifo 
queue priority 
rootjob 

run continuous 
size 120 bytes 
Space 
Supervisor job 
th read 

th write 

wait forever 


word, 
byte, 
word, 
(5) byte, 
word, 


) byte) ; 


literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 
literally 


"OFFH'; 
'O39H'; 
'ODH'; 
‘while 1's; 


a 
'O3H': 
"OFFFF 
'120'; 
"20H'; 
'OOH'; 

a 


H'; 


"O1H'; 
"OSH'; 
'OFFFFH'; 


/* The following declaration sets the characters */ 
/* to send the cursor home at the beginning of */ 
/* each message to the display screen. 


/* seqeunce is tilde, 


declare 


declare 
declare 


declare 


declare 
declare 


DC2 (Hazel 
cursor home chars(2) 


frame pointer 

frame _pointer values 
offset word, 

base word) at (@frame po 


tine)). 


pointer; 


The x / 


ay 


byte data (07EH,012H,) ; 


structure ( 


inter) ; 


frame based frame _pointer structure ( 


Samples per frame 
Sample _ interval 
frames to average 
continuous flag 

this frame number 
number _samples__ missed 
Sample > _pointer — 

reset flag 
sample(256) 


th_in_ segment pointer 


th in _segment __ _pointer_ values 


offset word, 
base 
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word, 
word, 
word, 
word, 
word, 
word, 
word, 
word, 


integer); 


pointer; 


structure ( 


word) at (@th_in_ segment pointer); 
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141 


142 
143 


144 


145 


146 


147 


148 


149 


150 


Ld. : 


declare 


declare 
declare 
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th in _segment based th_ in _segment pointer 
structure ( . 

function a a word, 
“GOunt. © 45 46: 4 < word, 
exception code © | word, 
gacttal, 8. cwee * a word, 
message(112) | byte) ; 

th out segment pointer - pointer; 


th out segment _ pointer values ‘Structure ( 
offset word, 


base word) at (@th_ out ee ramene _pointer) ; 


| declare 


declare 


declare 


declare 


declare 


declare 


declare 


th out _segment based th_out Bee pointer 
structure ( 
function | ee 
count * 4 | ~- word, 
- exception code | word, 
actual | | word, 
home chars(2) 5 °°. . byte, 
line index(24) | - byte, 
message (84) aa -- byte); 
frequency question(*) byte data ('Please' 
' enter the highest frequency in Hz (120, 
" 600, 1200, 6000, OR-12000):'); 
frequency answers data(*) byte data (05H, 
03H,03H,04H,04H,05H,0H, 
" 120 600 1200 600012000 ar 
42H,OFH, OODH,93H, 087H,0O1H,. 
4AEH,OOH, 0O27H,OOH, OOH, EO 
average | question(*). yee data ('Please' 
'" enter the number of frames to. average 
" (1, 2, 4, 8, a OR “3 2)-2°) 4 
average answers data(*) byte data (05H, 
O1H, O1H, 01H,01H,02H,02H, 
as 1 ie 4 8 16. 32% y 
01H, OOH, 02H,O0H, 04H,00H, 
08H,QOOH, 10H,O0OH, 20H,(OH); 
continuous question(*) byte data ('Please' 
' enter ''lT'! for one sample run or ''c!!! 
' for continuous running:") ; 
continuous answers data(*) byte data (03H, 
01H,01H,01H,00H,00H, OOH, 
: 1 c c Lg 
OOH,OOH, OFFH,OFFH, OFFH,OFFH, 
O0H,OOH, OOH,OOH, Q00H,OOH);. . 
reject _message(*) byte data ('I cannot! 


declare 


' accept your answer. PLEASE TRY AGAIN.'); 
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declare status line one(*) byte data ('Current' 
| " settings are the following: frequency' 
' range 0 to Ha; )\¢ 


declare status line two(*) byte data (' ! 
' frames to average per output display,' 
' and se 


declare continuous runs(*) byte data 
(‘continuous runs.'); 


declare single run(*) byte data 
(‘a Single run. oe 


declare go ahead question(*) byte data (‘TE '! 
‘these settings are correct, enter ''G'' ! 
‘to begin running.'); 


declare header line one(*) byte data (' INTEL' 
' APNOTE 110--THE iRMX 86 OPERATING SYSTEM! 
' AND iAPX 86 COMPONENT DESIGNS.'); 


J RRR RRR RRRER REE R RE EKRRERKRREKREKKRREKEREKEREREKREKREKEKEKKE / 


/* The following three procedure declarations * / 
/* link the tasks outside the SUPERVISOR MODULE */ 
/* with the supervisor task. * / 


[ RRRRREKREK KKK KKK KKK KKK KKK KKKE KEKE KE RERKEKKEE KKK EKER / 


INPUT TASK: PROCEDURE EXTERNAL; 
END INPUT TASK; 


FFT TASK: PROCEDURE EXTERNAL; 
END FFT TASK; 


OUTPUT TASK: PROCEDURE EXTERNAL; 
END OUTPUT TASK; 


[RRR RRR E REE KERR KERR REKERKEREREEE / 
[BRR RK KEKE KEKEKREEKEKKREE KEKE KEREKRE RR KEK / 


/** The following five procedures are general **/ 


/** utility procedures called by the primary **/ 


/** working procedures. + / 
J RRR RRRRREKRE KEKE EKER RE RRERERERERKERERERREEEKE / 


[RRR KRERE RRR RE RE KRKERERREEREREERE RK / 


[J BRRREKRKERKEKRRERE KEKE KEKE RREREKRREREKREKERERERE / 


/* Blank line just fills the message buffer */ 


/* with blank characters. * / 
J BRR RRR RER ERE RRR ERR EKER RE RE RERKERREER REE / 


BLANK LINE: PROCEDURE; 


declare blank line index word; 
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do blank line index = 0 to 78; 


th _out. segment. message (blank_ he _index) 
| = space; | 
end; 


th out segment.message (79) = carriage return; 
END BLANK LINE; 


AICI III III II II III II IITA IA] 
/* DISPLAY LINE sends the message to the */ 
/* terminal handler output mailbox ‘and x / 


/* waits for the segment to be returned. */ 
i aaa) | 


DISPLAY | LINE: PROCEDURE; 


call ra$sendSmessage (th out Coe 
th out | _segment token, 
: : 7 | return th out mbx, @status) ; 
th out segment token = rq$receives$message 
— (return th out mbx, 
wait _forever, @dummy__ mbx, 
@status; ) 


END DISPLAY LINE; 


[RRR RE RR EKER RE REKREEKREREEKREREREREERREKERE / 


/* INSERT TEXT. fills the output message segment */ 
/* with the chosen message and pads the rest of */ 


/* the line with blanks. * / 
[BRR IR RIOR IO TOI IIR TOTO TOR OR TOR TOR TOR TOR IORI OR KR IO / 


INSERT TEXT: PROCEDURE(TEXT POINTER, HOW MANY) ; 


declare text pointer | _. pointer; 

declare how many word; 

declare .. dummy based text pointer structure( 
Be entries(80) byte); 

declare insert text _index word; 

do insert text index = 0 to (how many - 1); 


th. SOUL. - segment. message (insert __ text index) = 
dummy.entries. (insert _ text. _index); 
end; 


do while insert text index < 79; 
th out _segment. message ae pene _ index) 


= space; 
insert text_ index = insert _ text ides + 1 
end; 
th out segment.message (79) = carriage return; 


END INSERT TEXT; 
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[J RRERRRKERERERERHEKREK ERE KERR ERE REKREREEKKRREEKKERKEKEEK KE / 
/* Move down line puts the required number of */ 


/* Line feed characters in the first Sth x / 
/* through 29th character of the output * / 
/* message. Each line is displayed on the */ 
/* screen in its proper location. This allows */ 
/* multiple tasks to access the screen * / 
/* without having to blank the line each */ 


/* time. This technique assumes each message */ 


/* sends the cursor home each time. 
[J RRRRKRKRER KEKE KEE IKRERKERE KER EERE KRRKREKKRRRERERE / 


MOVE DOWN LINE: PROCEDURE (SKIP LINES) ; 


declare skip lines word; 
declare move down line index word; 


if skip lines > 0 then 
~do move down line index = 0 to (skip lines - 1); 
th out segment.line index (move down line index 
= line feed; 7 i - 


end; 
do move down line index = skip lines to 23; 
th _out _segment. wline_ index (move down line index) 
= null; 
end; 


END MOVE DOWN LINE; 


J RRRRREREKRRER ERR KER ERE RRR EREKERERKEREKREREKEKRKEKREKREKRE / 


/*. SEND REJECT MESSAGE is called by INPUT * / 
/* PARAMETERS. It just sends a reject message */ 
/* to the CRT to inform the user that the * / 
/* answer the user gave was not valid. a A 


J RRR RERKRREKR EER ERR ERR ERE KEKEREKERKEREKEEKEKKKKEKKERKEKERE / 


SEND REJECT MESSAGE: PROCEDURE; 


call move down _ line (21); 
text _length = size(reject message) ; 
insert text _pointer = @reject message; 


) 


call insert text (insert text _pointer, text length); 


call display_ line; 


END SEND REJECT MESSAGE; 


[RRRREKERERKEREKEEEKR REE RRR RERKEREREKRKERKERERKEREKRKEKKE KR / 
JL RRRRRRERERKEKRREREREREK ERR RE RERRREREKERREEREKEEEEKERE EK / 


/** The following procedures are the primary hal A 


/** working procedures called by the supervisor **/ 


/** procedure and its called procedures. x / 
J BRR RRR RE RK ERKREKEEKREKREKRKERERKEEERKEKREKRKEKRERREREREREERE / 


[J RRRRRREREKRERREKRRER ERR ERE KREKRRERERERERERKEEREREEERERER / 
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(III III III II IO II TOIT ITT TIO TORTI RII / 
/* PURGE MAILBOX removes all tokens from * / 


/* a mailbox. The purpose is to remove segments */ 
/* waiting for processing by one of the tasks */ 


/* if the operator has specified an abort * / 
/* request. If the segment deletion was */ 
/* successful, PURGE MAILBOX a the * / 
/* segment | deleted tally. * / 


LASERS ae ARES ARR RA a ADOT Ca VERNA eee e/ 


| PURGE MAILBOX: PROCEDURE (MAILBOX_TO PURGE) ; 


declare mailbox to purge token; 


declare for 110 milliseconds literally 'OBH'; 


declare message received literally 'OH'; 
declare contents token token; 
declare purge dummy mbx token; 
declare purge status token; 


purge statuS = message received; 


do while purge status = mesSage received; 
contents token = rq$receiveSmessage 
(mailbox to purge, for 110 milliseconds, 
@purge dummy mbx, @purge status) ; 


if purge status = message received then 
do; 
call rqSdeleteSsegment 
(contents token, @purge status); 
segment_deleted _tally = 
| segment _ deleted tally + 1; 
purge status = Ul _received; 
end; 7 
end; 


END PURGE MAILBOX; 


J RRRERRREERREREKRERRREREKREER EERE RE RKERERERKEKRERERERERE / 


/* MONITOR MAILBOXES polls the | | */ 
/* return th in mailbox and the © a i 
/* to _supervisor_ mailbox for messages. The * / 


/* messages will be abort (from the operator), */ 


/* and FFT done or OUTPUT done if the runs are */ 


/* not continuous. If the runs are not * / 
/* continuous and an FFT done message is * / 


_f*® received, MONITOR _MATLBOXES will initialize * / 


/* the OUTPUT task. : * / 
[RRR ERKEEREREREREKEKRE RRR KEKE RKEKRREKEEEKREEREREREEEKK / 


- MONITOR MAILBOXES: PROCEDURE; 
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226 2 declare cannot wait | literally 'OOH'; 
227 2 declare done ~— literally 'OFFH'; 
228 2 declare for 400 milliseconds literally '"28H'; 
229 2 declare message _ ~ received literally ‘QOH'; 
230 2 declare not done literally ‘'OOH'; 
231 2 declare monitor dummy mbx token; 
232 2 declare monitor token > token; 
233 2 declare monitor status token; 
234 2 declare done flag byte; 
235 2 declare monitor index word; 
236 2 done flag = not done; 
237 2 | segment deleted tally = 0; 
232 2 call rq$sendSmessage 
(th in _mbx, th in segment token, 
return th_ in mbx, @status) ; 
239 2 do while done flag = not done; 
/* Check for operator input here. */ 
240 3 monitor token = rqSreceiveSmessage 
(return th_in_mbx, for 400 milliseconds, 
@monitor dummy _mbx, @monitor status) ; 
241 3 if monitor status = message received then 
242 3 do while segment deleted tally < 
number of fft data segments; 
243. 4 3 call purge mailbox (to fft_mbx); 
244 4 if segment _ ~ deleted tally < 
number _ of ft data _segments then 
245 4 call purge mailbox (to input mbx) ; 
246 4 — if segment _ deleted tally < 
number Ore fft data _segments then 
247 4 | call purge | mailbox (to _supervisor _mbx) ; 
248 4 if segment _ deleted tally < 
number 206. fft data _segments then 
249 4 call purge | mailbox (to output mbx) ; 
250 4 oo _flag = done; 
251 4 end; 
252 5 | if done flag = not done then 
253 3 do; | -_ 
254° 4 - monitor token = rq$receiveSmessage 
(to _supervisor mbx, for 400 milliseconds, 
@monitor _dummy _ mbx, @monitor _status) ; 
255 4 if monitor status = message _ received then 
256 4 do; -_ 
257 5 ie parameters.continuous flag = 


run continuous then 
258 5 call ~ rq$send$message 
| | | | (to input _mbx, monitor _token, 
no response requested, 
@monitor status) ; 
else cer 
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259 5 do; 
260 6 call rq$delete$segment 
| (monitor token, @monitor status) ; 
261 6 segment _ deleted tally 
= segment _ deleted _tally + 1; 
262 6 if segment _ deleted _tally 
= number of fft _data _segments 
then done flag = done; 
264 6 end; | 
265 5 end; 
266 4 end; 
267 3 end; 
268 2 END MONITOR MAILBOXES; 
[RRR KERR REKKRKEERERE REE RERERERKEREKEKKE / 
/* SET SEGMENT initializes the common parameter */ 
/* areas of the segment. The pointer to the * / 
/* proper segment is set up by */ 
/* INITIALIZE SEGMENTS. 
[RRR RRR RRR REE ERR RRR ER ERE KERR REE RR REE KK KKK / 
269 1 SET SEGMENT: PROCEDURE; 
270 2 frame.samples per frame = 128; 
274 2 frame.sample _ interval. 
= parameters.actual interval; 
272 2 frame.frames to average 
= parameters.actual frames to average; 
273 2 frame.continuous flag = parameters.continuous _flag; 
274 2 frame.this frame number = QOH; 
275 2 frame.number samples missed = 00H; 
276 2 frame.sample pointer = 00H; 
277 2 frame.reset flag = OOH; 
278 2 END SET SEGMENT; 
J RRR REE KK RRR KER RKERKRERRRERERERKEKEEREE / 
/* INITIALIZE SEGMENTS creates the three FFT */ 
/* data segments and calls SET SEGMENT for each */ 
/* segment to initialize the common parameter ue 6 
/* areas of the segments. ui 
[BRR RRERERRRERE RRR EREK ERR EKEKRERRERERERKEEEEEREREREE / 
279 1 INITIALIZE SEGMENTS: PROCEDURE; 
280 2 declare size 528 bytes literally '528'; 
281 2 frame pointer values.offset = 0; 
282 2 frame segment one = rqScreateSsegment 
(size 528 bytes, @status) ; 
283 2 frame _pointer_ values.base = frame segment_one; 
284 2 


call set segment; 
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frame.reset flag 
number of f£t data segments 
call rq$SsendSmessage 
(to input _mbx, frame segment one, 
no response requested, @status) ; 


new fft run; 
1; 


if parameters.actual frames to average > 1 then 
do; 
frame segment two = rqScreateSsegment 
(size 528 _bytes, @status) ; 
frame pointer values.base = frame segment two; 
call set segment; — 7 
number of fft data segments = 2; 
call rqSsendSmessage 
(to input _mbx, frame _segment two, 
no _response | requested, @status); 
end; 


if parameters.actual frames to average > 2 then 
do; 
frame segment three = rqScreateSsegment 
= (size 528 bytes, @status); 
frame pointer values.base 
7 ~ = frame segment three; 
call set segment; - _ 
number of fft data segments = 3; 
call rq$send$message 
(to_ input _ mbx, frame segment three, 
no response requested, @status) ; 
end; 


END INITIALIZE SEGMENTS; 


J RR RRRKRERERKERKERERRE REE KEKE KR RKEKREREEKERKEKKEKERRKEEKKK / 
/* INPUT PARAMETERS contains three procedures: */ 


/* set _question _pointers, get answer, * / 
/* and verify answers. The INPUT PARAMETERS x / 
/* loop consists of calls to these three * / 
/* procedures and, as uSual, exists at the end */- 
/* of the procedure. */ 


J RR RRRKRKERRERERKER EERE EKER ER EKER REEKEREREKRKEEKEEEK / 


INPUT PARAMETERS: PROCEDURE; 


declare actual pointer pointer; 
declare answer pointer pointer; 
declare answer _display_ pointer pointer; 
declare question_ pointer pointer; 


declare answer actual value based 
actual pointer word; 


declare answer overlay based 
answer pointer structure ( 
number of answers byte, 
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eee. 
word) ; 


answer _display based 


answer display pointer structure( 


characters(5) byte); 


answer byte index 
answe 


answe 


r index 
r match 


byte match 


input _byte index 
output _byte_ index 
question_number 


Stop byte 


ascii 


ascii _capital | G 
average | entry point 
continuous _entry_ point 
frequency _ entry_ point 


match 
no_ma 


small g 


tch 


not negative 


nothing returned 


byte; 

byte; 

byte; 

byte; 

byte; 

byte; 

byte; 

byte: 
literally '0O67H'; 
literally '0O47H'; 
literally 'O'; 
literally '48'; 
literally '58'; 
literally ‘'OFFH'; 
literally ‘'OOH'; 
literally '< 255'; 
literally 'QOH'; 


set question pointers: procedure; 


do case question number; 


do; 


text length = 

question pointer 

answer pointer = 
actual pointer = 
. answer _display_ pointer. 
| @parameters. frequency answer; 


end; 


do; 


text length = 


question pe eee 
answer _pointer 
- actual _pointer : 
: @parameters.actual _ frames _ to_ average; 
answer _display pointer. 


end; 


do; 


@parameters. frames _ to _average answer; 


text Senger s 


size (frequency question) ; 
@frequency question; 
@frequency answers data; 
@parameters. actual “interval; 


size (average question) ; 
@average_ question; 
= @average answers data; 


size (continuous question); 


question pointer = @continuous _question; 
-answer_ pointer = 
actual pointer = 
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answer display pointer 


end; 
end; 


end set question pointers; 


get anSwer: procedure; 


/* First display the question to be answered */ 
/* by the operator. * / 


call insert text (question pointer, text length) ; 
call move down line (19); 
call display line; 


/* Then blank the line below for an answer line. 


call blank line; 
call move down line ae 
call display line; 


/* Now wait for a response from the operator. */ 


call rqSsendS$message 
(th_in_mbx, th in _segment token, 
return th in mbx, @status) ; 
th_in_ segment token = rqSreceiveSmessage 
(return th in _mbx, wait _forever, 
@dummy _ mbx, @status); 
th_in_ segment __ pointer values.base 
= th_ 1 _segment token; 


/* T£ there is no message returned then send */ 
/* a reject message. * / 


if th_in_segment.actual = nothing returned 
then call send _reject message; 


/* Otherwise it is time to check the response */ 


/* against the possible answers. aly 
else 
do; 
answer _ match = no match; 


/* Set the number of possible answers. */ 


answer index 


= @parameters.continuous flag answer; 


a7 


= answer overlay.number of answers; | 


/* Start a loop to check all of the */ 
/* possible answers. */ 
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370 086=6 4 do while (answer match. = no _match) and 
| oon e (answer index > (007 


/* Set the starting point for the &/ 
j* pies by ‘byte compare. a7 


371 5 answer _byte_ index = (answer_ index * 5) - 1; 


/* Set the stopping point for */ 


/* the ee * / 
372. 2 5 OO stop _pyte = answer _byte index 
- answer _overlay. length_of answer 
(answer _ index eee 


/* Start with a "match" eee can */ 
/* check until "no match" occurs. */ 


373 5 byte_ match = match; 


/* Set Sear ting? ‘point at the right end ey 
/* of the input: data (allows us to * / 
/* ignore leading blanks and the * / 
/* ending carriage return). */ 
374 5 input ese Pte, = th in segment.actual-2; 
/* Scan the bytes until all pertinent */ 
/*. ones are checked or a "no. match" * / 
/* occurs. | * / 
375 5 -. do while (byte ‘match = match) and 


(answer _byte_index > stop byte); 


376 6 if (input _byte_ index not _negative) 
. ay es then: do; 
S76) 2° if th_in_ segment. message 
(input _byte_ index) = 
answer _overlay.values | to match 
(answer _byte_ index) 
then byte match = match; 
380 . 7. . | _ else ay eenaeey = no match; 
381 7 bee end; ; 
382 6 else byte_ even: = no match; 
383 6 answer byte index = answer byte index-1l; 
384 6 input byte index. = input byte index -1; 
385 6 end; 7 -_ 
/* A "match" at this point means ALL */ 
/* bytes matched. a a 
385 S) | Pld byte. match = match then 
387 5 . po do; y 4 
/* Set real values via * / 
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388 
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395 


396 


397 
398 
399 


400°. 


401 
402 


403...) 


405 
406» 


407 


1) 


SY OY 


DAADD 


 f/* answer actual value overlay. */ 


~. answer actual value 
= answer overlay.really are 
(answer index - 1); _ 
answer match = match; 


/* Insert displayable values for */ 


/* later display. * / 
answer byte index = 4; 
input _byte_ index = (answer index*5)-1 


do while answer byte index not negative; 
answer _display. characters 
(answer _byte_ index) 
= answer overlay.values to match 
(input byte index); — 
input byte index — 
= input byte index - 1; 
answer byte index _ 
= answer byte index - 1; 
end; = .. Me 


/* We got a match, so be sure the */ 
/* reject message line is blanked. */ 


' ¢all move down line (21); 
call blank line; 
call display line; 

ena oe ee ee 


/* I£ no match, then let's compare the */ 
f/*-input with the next. possible answer. */ 


else answer index = anSwer index - 1; 
end;. - a” a: 7 
/* If we got a match, then-:we can move on */ 
CN the next ee Ge ORs */ 
if answer ares ‘match | 
7 then Seer ea eee = question number + 1; 
/* Otherwise we have to check for an */ 
/* abort request of '99', © * / 
else 
do; — | 
input - _byte_ index = th_in segment.actual-2; 
if (th in _Segment. aoe ee byte _ index) 
“ = ascii =. 
and 


- co in _segment. message (input _byte_ index - 


= ascii 9) chen 
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/* Abort requests are valid, so blank */ 
/* the reject message line and reset i 


/* the question: number so we start */. 
f/* asking all over. * / 
408 5 do; —_ 3 t es 
409 A question number = 1; 
410 6° call move down line (21); 
411 5 ‘call blank _line; 
412 6 call atser ay line; 
413 6 end; | 
ae else 
/* But if nothing matched and the */- 
/* answer. waS not an abort request, * / 
/* then we have to ask the operator * / 
/* to try again on this question. */ 
414 5 call send reject message; 
415 5 oo ends | 
416 4 end; | 
417 3 end get answer; 
418 2 2 verify answers: procedure; 
/* First put the es in the buffer. */ 
419 3 text _length _ | = size (status line one); 
420 3 call insert __ text (@status_ line _one, text _Tength) ; 
_-/* Then insert the displayable frequency answer. */ 
421 3 input byte index = 0; | 
422 3 stop_ byte = eredueney 2 entry point + 4; 
423 3 do output Be Gee index 3 
7 : | frequency . entry_ point to stop byte; 
424 4 th out “segment. message (output _byte_ index) = 
: parameters. frequency answer (input_ _byte_ index) ; 
425 4. input_byte index = Input _byte_ index + 1; 
426 4 end; 
427 3. eall move down line(19); 
428 3 call display line; 
/* We have sent the first line, now it is time */ | 
/* to get the second pee RS 
429 3 i text _length - = size (status line two); 


430 3 call insert text eee r ee line _two, text _Tength) ; 


y* We have to insert the ‘qieplavabie "frames */ 
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/* to average" answer. */ 


input_byte_ index 
Stop byte 
do output _byte index 
= average entry point to stop byte; 
th_ out segment.message (output _byte_ index) = 
Parameters.frames to _average answer 
(input byte_ index); 

input _byte_ index = input byte index + 1; 

end; 


0; 
average entry point + 4; 


/* The continuous answer is different--we have */ . 


/* to decide if we have continuous runs or */ 

/* single runs, and insert those words in the ¥*/ 

/* display line. * / 

input byte index = 0; 

stop byte — = continuous entry point + 15; 

if parameters.continuous _flag = run_ continuous 
then 


do output byte index 
= continuous _entry point to stop byte; 
th out segment. message (output _byte_ index) = 
- Continuous runs (input _byte_ Index) ; 
input byte_ index = input _byte_ index + 1; 
end; | 
else 
do output byte index 
= continuous _entry point to stop byte; 
th out _segment.message (output _byte_ index) =. 
Single run (input _byte _ index) ; 
input byte index = input byte index + 1; 
end; . 


/* Then send the message and wait for a response */ 
/* from the operator. */ 


call move down line(20); 
call display line; 


text length = size (go ahead question) ; 

call insert text (@go ahead_question, text_ length); 
call move down line (213 

call display_ line; 


call blank line; 
call move down line(22);. 
call display line; 


call rqSsend$message 
(th_ in _mbx, th in _segment_ token, 
- return th. in _mbx, Aastatus); 


= rq$receive$message 
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(return th_in_mbx, wait _ forever, 
@dummy | mbx, @status) ; 


459 3 th_in_ segment __ Pon eee values. base 
| | | ‘th _in segment _ token; 
460 3 0 input byte index = th_ in _Segment. actual - 23. 


/* Check for a "g" or "G" (we aren't fussy). If */ 
/* we got it, let's quit asking the selection */ 
/* questions and go. If.not, we have to start */ 
/* at question 1 again rather than try to find */ 


/* out which of his or her answers wasn't * / 
/* acceptable. * / 
461 3 if’ (th_ in segment. message (input _byte_ index) 


= ascii small 9). or 
(th_in_ segment. message (input _byte index) 
= ascii capital _G) then; 


463 3 else question number = 0; 

464 3 call blank line; 

465 3 call move down line (21); 

466 3 call display line; _ 

467 3 end verify answers; 
[RR RR Rk Rk RR RR RR Rk RR kk RR RR OR K/ 
/* As usual, the actual INPUT PARAMETERS control */ 
/* loop is at the end. * 
[ek Rk Rk Rk RR Rk Rk kk Rk Rk kk Rk Rk Rk KR RR RS 

468 2 — question number = 0; 
/* All we do is get the next question, ask the * / 
/* question until it is answered successfully, */ 
/* ask all of the questions, then check all of ae 
/* the answers. If the operator doesn't like */ 
/* the set of answers, we loop through them */ 
/* again. First we make sure the reject message */ 
7* line and other pertinent lines start out © a 
/*® blanked. | | | * / 

469 2. call blank line; 

470 2. call move down line (18); 

471 2 call display line; | 

472 ? call move down line (21); 

473, 2 call display line; 

474 2 call move down line (22); 

475 2 call display line; _ 

476 2 call move down line (23); 

477 2 call display line; 

478 2 input_ loop: do while question_ number < 3; 

479 3 | call set _ question _pointers; 

480 3 call get_ answer; 
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end; 


call verify answers; 
if question number = 0 then goto input loop; 


END INPUT PARAMETERS; 


J RRR ERK ERERERERERKRERERKEEKEEREREERKEE / 
/* INITIALIZE TASKS initializes the INPUT TASK */ 
/* and the FFT TASK. If the FFT runs are to be */ 
/7/* continuous, INITIALIZE TASK also initializes */ 


/* the OUTPUT TASK. If the runs are not * / 
/7* continuous, the OUTPUT TASK is initialized */ 
/* by MONITOR MAILBOXES. * / 


J RRR RHR HK RRR EKER ERE KARE EKER ER REEEKRKERE KEE / 


INITIALIZE TASKS: PROCEDURE; 


declare hardware interrupt level 3 literally '038H'; 
declare no data _segment literally 'OOH'; 
declare nucleus allocated stack literally ‘'OOH'; 
declare software _priority_ level 67 literally ‘'A7'; 
declare software — _priority_ level 130 literally '130'; 
declare software priority level _ 131 literally '131'; 
declare stack size 512 literally '512'; 
declare task flags literally 'OOH'; 


input task token = rqScreateStask 
~ (software priority level 67, @input_task, 
no data _segment, nucleus allocated “stack, 
stack size 512, task flags, @status) ; 


call rqScatalogSobject 
(supervisor job, input_task_ token, 
@(10,'INPUT TASK'), @status); 


fft task token = rqScreateStask 
(software _priority level_131, @fft_task, 
no data _segment, nucleus allocated stack, 
stack size 512, task _flags, @status) ; 


call rq$catalogS$object 
(supervisor job, fft_task_ token, 
@(8,'FFT TASK'), @status); 


output task token = rqScreateStask 
(software _priority level _130, foutput task, 
no data _Segment, nucleus allocated stack, 
—stack_ size _512, task flags, Astatus); 


call rqS$catalogSobject 


(supervisor job, output_task_token, 
@(11,'OUTPUT TASK'), @status); 
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501 2 END INITIALIZE TASKS; 
J RRRRKRERRREERRRERRE KERR KEREKRERERERERRERERREEEKREKER / 
/* Initial screen displays the initial two Sf 
/* lines on the screen and sends blank lines * / 


/* for all the other lines‘‘of the first screen. */.« 
ela halal A Ca Se i! 


502 bec INTTTAL_ SCREEN: PROCEDURE; 
503 2: + declare 1 initial _Screen_ index word; 
veall move | Sawn: dine (0); 


a oe 
505. 2 call blank line; . 
go I Qee SP ea display line; 


507 2 call toe en. line(1l); 
508 2 text length = size(header __ line _one); 
509 2 insert text _pointer = @header__ line _one; 
510. 2 .. call insert. text (insert text_ _pointer, text léngth) ;. 
511 2 call ies tas line; bed ok | ve eens 
512 2 call blank “line; sare ee 
643% 2S MAO initial _ screen index= 2 £0: 223% 
514 °3.°°. °° eall move down line (Osea screen: index) ; 
SLD) 4.374%, 23, eat display line; . : 
5.14 3 o> ends: pws 
517 2 END ENE DERE EehnaNy 
Pe PeR TEC COTeC CCE TCCTee eT TCeeeceeeeet cere’, 
/* INITIALIZE BUFFERS takes. care of the */ 
/* initialization required for general */ 
/* SUPERVISOR TASK start up. °° */ 
dag ad ha ae gece 
518 l INITIALIZE _BUFFERS: ‘PROCEDURE; 
519 Mae, “return_ th. in Te = yaSereavestel ines 
pte Re eee ‘(queue __ fifo, @status) ; 
520 Ds bit Cal. $aeedealoasobdece : i 
(supervisor _ job, eecurn th in _mbx, 
| Q@(9,"SUP TH-IN') ,.@status); 
521 2 return: th. aout mbx = rqScreateSmailbox 
(queue fifo, @status) ; 
522 2 call rgScatalogsobject 
| (supervisor:.job, return th out_mbx, 
pe SCP eee .. @(10,'SUP TH -OUT'), @status); 
523 scBoe op ettow input _ mbx - +. = rq$createSmailbox 
POM ah ar : (queue fifo, @status) ; 
524 2 call Gaseateiogsobject 


(supervisor job, to_input mbx, | 
mee et eh 38 @(12,'TO INPUT :MBX'), @status) ; 
525 2 to fft:mbx = rq$createSmailbox 
— (queue priority, @status) ; 
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call rqScatalogSobject 
(supervisor job, to fft mbx, 
@(10,'TO FFT MBX'), @status) ; 


to Loot pene mbx = rqScreateSmailbox 


(queue Priority, astatus) ; 
call rqscatalog$object . 
(supervisor job, to output mbx, 
@(10,'TO OUT MBX'), @status); 
to supervisor: mbx = rq$ScreateSmailbox 
‘(queue _priority, @status) ; 
call rq$catalog$object 


(supervisor job, to supervisor mbx, 


@(10,'TO SUP MBX'), @status); 


root job token = rqSgetS$taskStokens 
(rootjob, @status) ; 
th out mbx = rqSlookupSobject 


(root job token, @(11,'ROTHNORMOUT'), 


wait forever, @status) ; 
th_in_mbx a = rqSlookupSobject 


(root _job_ token, @(10,'ROTHNORMIN'), 


wait _ forever, A@status); 


th_in_segment_ token = rqScreateSsegment 
(size 120 _bytes, @status) ; 
call rq$catalog$object 


(supervisor job, th in _segment _ token, 


@(10,'S THIN SEG'), @Status); 
th_in_segment pointer values.offset = 0; 
th. in _ segment pointer _ ~ values.base | 

= th_ in_segment_token; 
th_ in segment.function © = th. read; 
th_in_segment.count | = 82; 


th_out segment token = rqScreateSsegment 
(size 120 _bytes, @status) ; 
call rq$catalogSobject | 


(supervisor job, th out segment token, 


@(11,'S THOUT SEG'), @Status) ; 
th_out_ segment pointer values.offset = 0; 
th _out _ segment pointer _ ~values.base 
= th out _segment token; 
th out _segment. function = th _write; 
th out segment. count = 111; 


do general index = 0 to 2; 
th out _segment. home chars (general index) 
= cursor home _chars (general _ index) ; 
end; 


END INITIALIZE BUFFERS; 


[ BRRRREKREREEER EERE RERERERE EERE KKEEKKEKREKKKREKREKKKEE / 
/* At last, the SUPERVISOR TASK! All it does is */ 
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/* call other procedures. to:initialize the . kf 
J/*  sereen,,input. the.parameters, clean up the * / 


= ./*® old FFT-segments, from the mailboxes, set up * / 


/* new segments, create the. tasks, and then wait */ 


./* for.messages from-the operator papont) or a 


/* other tasks (FFT or OUTPUT. done) « * 
[OO TAT EE ET EATAA 


SUPERVISOR. _TASK: PROCEDURE. PUBLIC;.. 


call initialize “buffers; 


call goheia a ey 


call initial screen; 
call initialize_ tasks; 


o., do forever; 


ari input_ pabanecres 
call initialize segments; 
call monitor mailboxes; 


"eGge 


END SUPERVISOR. LTASK; 


END” SUPERVISOR. _MODULE; 


MODULE INFORMATION: | 


CODE AREA SIZE 
CONSTANT AREA SIZE 
VARIABLE AREA SIZE 
MAXIMUM- STACK SIZE. 
1197 LINES: READ. 


1032H-: 4146D. -.... 


= 0OOOH °° OD... 
= 0084H 132D 


,0024H  ... 34D... 


0 PROGRAM M ERROR (S) 


END OF  PL/M-. 86 COMPILATION 
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ISIS-II PL/M-86 V2.0 COMPILATION OF MODULE | INPUT | TASK | MODULE 
OBJECT MODULE PLACED IN :Fl:input.OBJ | 
COMPILER INVOKED BY: plm86 :Fl:input.p86 
Stitle('INPUT TASK FOR AP Note nae OCTOBER 1980') 
.. Slarge debug | , 
INPUT TASK MODULE: 
do; e 
Sinciude(: fl: nucprm. ext) 
= .. $SAVE NOLIST . . 


89 1 declare Soren. a literally 'word'; 


7) The folvowtng two arene the FFT sample * / 
.. f* segment format, and the root job directory *f 
- f/*® form the entire interface for this task with */ 


-f*® the rest of the oust ens | : * / 
90 id. secure to ‘input_ oi | | token external; 
91 l declare to fft_mbx token external; 
92 1 declare ascii mask — oie, | literally '30H'; 
93 1 declare carriage | return aa literally 'ODH'; 
94 1 _..declare. done -- | me literally 'OFFH'; 
95 ] declare first loop literally 'OFFH'; 
96 1 declare forever |. eee literally ‘while 1'; 
97 1 declare frames to process entry literally '50'; 
98 1 declare hardware _interrupt_ level 3 

_ literally '0038H'; 

99 1: declare, interrupt . task created literally ‘'OFFH'; 
100 ] declare interrupt _ ~ task | not created literally 'OOH'; 
101 1 declare latch the data literally '0O40H'; 
102 i} declare line feed tir. <2 » literally 'OAH'; 
103 ] declare new_ fft_ run. > 3 _literally 'OFFH'; 
104 1 declare no _response__ paquesese literally 'OOH'; 
105 1 declare no data segment | — Jiterally 'OOH'; 
106 1 declare not done a : literally 'OOH'; 
107 1 declare not first loop. literally 'OOH'; 
108 1 declare not valid literally 'OOH'; 
109 1 declare null ok ee literally '‘OOH'; 
110 l declare processed so _ far “entry literally '33'; 
111 1 declare queue _ fifo — : .  - literally 'OOH'; 
112 l declare rootjob | literally '0O3H'; 
113 1 declare run continuous . ci literally 'OFFFFH"'; 
114 1 declare sample _ LSB 2% literally 'OO81H'; 
TiS 1 declare sample _MSB oh am Fe literally 'OO8OH'; 
116 1 declare size 2 bytes literally '2'; 
117 i 4 declare size 120 DYECS 3.» « ™“ ot bterally "220%; 
118 1 declare supervisor job. ' literally 'OOH'; 
119 ee declare th write —- literally '05'; 
120 1 declare this is the _interrupt_ task literally 'O1H'; 
V2 declare timer one port. : ~ . Jiterally ‘'OOD2H'; 
122 a declare timer _mode_ control. aROrE literally 'OOD6H'; 
123 1 declare valid | pe a : literally ‘OFFH'; 
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124 1 — gecnane Watt FOr ever ‘literally 'OFFFFH'; 
125 ] declare data Pasdgnent ‘token: | token; 
126 1 declare dummy _ mbx “token; 
127 1 declare from interrupt_ task _mbx token; 
128 1 declare handler dummy mbx token; 
129 1 declare handler status token; 
130 1 declare interrupt status — token; — 
132 1 declare interrupt task token token; 
132 1 declare interrupt message token token; 
133 1 declare output buffer token token; 
134 1 declare return mbx = “token; 
135. °d declare root job_ ‘token ©. ‘token; 
136061 declare signal _ aterrupe. token “token; 
137 1 declare status token; 
138 J] declare to _interrupt_ task _mbx token; 
139 21 declare th. _out_mbx © | token; 
140 1 declare sample data integer; 
141: 1 —:' declare sample input data SEreceere(: 
_ a LSB byte, | 
MSB bytey at (@sample_ data); 
142001 declare current_timer value ~ - word; 
143 1 declare timer values structure( os : 
ig #8 - | LSB _ byte, 
MSB ~—— byte) at (@current timer value); 
144 1 declare done flag byte; 
145 ° 1. declare figst_ input _ ioe: hag byte; =. 
146 1 -. declare frames received =—S——siby tte; 
147 1 declare general index — byte; 
148 °=1 declare interrupt task _flag byte; — 
149 =61 _ declare sample valid ©) pines 
150 1 declare timer threshold | word; 
1st 4 declare value_to convert word; 
152 1 declare adiveresdsusiuessecueturer 2 & 
a > first digit | byte, | 
second digit © 7 BYES) a 
/* The following declare is for the home */ 
/* characters for the Hazeltine terminals. */ 
Le The eodience is ehace ey BUes oe */ 
153 | 1 ‘declare cursor noms: _chars(2) byte data (O7EH, 012K) 5 
154 1 apetneer: 


declare output_ puffer _pointer. 7 
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declare output buffer _pointer_ values structure ( 
offset word, : 
base *. word): 
(aouebuecBUREer pointes); 


declare output buffer based output buffer pointer 


structure ( 


function ~— word, 
count word, 
exe Peron code: Were 
actual. word, 


home chars(2) byte, 
line index (24) byte, 
character(80) byte); 


declare data SSSR eS PoEnEcr pointer public; 


declare data _segment_ pointer_ values structure ( 
offset | ’ word, 
base. - eran ae 
(@data segment. pointer) ; 


f/* The eo eet eng the FFT data segment format. 


aeclaue data _ segment ree data pera pointer 
structure ( 


samples _per_ frame woes 
sample interval word, 
frames to _average word, 
continuous _flag word, 
this frame number word, 
number _samples | missed word, 
sample > pointer | Oa, “word, 
reset flag word, 
sample (256) integer) ; 
declare input status line(80): byte data 
(' The INPUT TASK has processed ', 
: frames out of Frames to! 
: average. i | a 


FAST. INPUT. HANDLER: 


PROCEDURE (FFT SEGMENT _ POINTER) EXTERNAL; 
DECLARE FFT SEGMENT _ POINTER EO 
END FAST INPUT _HANDLER; - 


*/ 


J RRRRERRRKRREREKRERERRK KERR ERR RKREEEKREKEREREREKERKEE / 


_/* SLOW INPUT HANDLER is an interrupt procedure 


/* that receives an interrupt when the 8253 
/*®* interval timer counts to zero. The &253 is 
/* free running, so it starts counting from the 


f® top again. The 8253 counter is tested 
/* in a polling: fashion to be sure it reads the 


/* sample, which resets the conversion, 
/* at a precise time. This aids in removing 
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f/* jitter from the sample intervals. When all */. 


/* of the samples have been taken, * / 
/* SLOW INPUT HANDLER calls signal interrupt, * / 
/* which lets the INTERRUPT TASK procedure know */ 


/* the buffer is full. * / 
[BRR ERR KR REE RE KIKEIK EEK IKEA KE / 


SLOW _INPUT HANDLER: PROCEDURE INTERRUPT 59 PUBLIC; 
/* First set the sample to not valid (we have */ 
/* to be past’the timer threshold before the */ 
/* sample becomes valid). */ 


sample _ valid. = not valid; 
timer _loop: 


/* Make the timer value stable and read it. */ 


‘output (timer mode _control port ) = latch the data; 


timer values.LSB = input (timer_ one _port); 
timer. values. MSB = input (timer one port) ; 


/* T£ it is not past the threshold, then some */ 
/* future compte will be valid. */ 


if current_ iivee: _value > timer _ threshold then 
do; 
sample valid = valid; 
goto timer loop; 
end; 


/* We get to the else only if we are past the */ 
/* timer threshold. * / 


else 

do; 
sample input data.LSB = input(sample LSB); 
sample input data.MSB = input(sample MSB) ; 


| /* If the sample is valid, we must have come */ 


/* in before the threshold so we know we * / 
/* sampled as close to the right time as */ 
/* possible. — | aa 


if sample valid = valid then 
do; 


/* However, we want to ignore the first */ 
/* sample (which was started a long * / 
/* time ago). , */ 


if first _input_ loop flag = first loop then 
first input _ Toop_ flag” = not first loop; 
- else pe = 
do; 
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data segment.sample 
(data segment.sample pointer) 
= Sample data; - 
data segment.sample pointer 
= data _segment.sample pointer+1; 
end; _ 
end; 
else 
do; 
data segment.number samples missed 
= data segment. number _samples | missed+l1; 


data _segment. sample _pointer = 0; 
end; 
sample_ valid = not valid; 
end; > 
If we are done, we have to let the * / 
INPUT TASK know the buffer is full. * / 
Otherwise, we wait for the next interrupt. */ 


data segment.sample pointer 
>= data _segment. Samples _per_ frame then 
call rq$signalSinterrupt 
(hardware interrupt level 3, 
@handler status); _ = 
lse — 
call rqSexitSinterrupt 
(hardware interrupt level 3, 
@handler status); — 


END SLOW INPUT HANDLER; 


/* 
/* 


/* 


KHKKKKKKEKKEKKEKEKKEKKEKEEKREKKEKKEKKEEKKRKEREKKKEKEKKKERKEKRKRKKKR / 


INTERRUPT TASK exists because if an interrupt */ 
task goes to sleep, the level of the * / 
interrupt task, interrupt handler, and lower */ 
levels remain disabled. In order to prevent */ 
this from happening in this application, this */ 
task notifies the INPUT TASK that the buffer */ 
is full. INPUT TASK disables Level 3 and - */ 
returns the token to INTERRUPT TASK. */ 
INTERRUPT TASK will then call wait interrupt, */ 
enabling lower levels. Since INPUT TASK * / 
disabled Level 3, no Level 3 interrupts will */ 
be serviced until Level 3 is enabled by * / 
INPUT TASK. | is 
*7, 

NOTE THAT PLM/86 REOQULTRES THE USE OF THE x / 
BUILT IN INTERRUPTSPTR PROCEDURE TO OBTAIN */ 
THE PROPER INTERRUPT PROCEDURE ENTRY POINT. * / 

‘ . + 

cis sou ees gheeearensak cere eaase erate 


INTERRUPT TASK: PROCEDURE PUBLIC; 
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call rqSsetSinterrupt 


(hardware interrupt level 3, 

this is the interrupt __ task, 
| INTERRUPTSPTR(SLOW INPUT “HANDLER) , 
no data segment, @interrupt status) ; 


do forever; 


call rqSwaitSinterrupt 
(hardware interrupt level 3, 
@interrupt_ Sieeus) 


call rqSsend$message 
(from interrupt task mbx, 
interrupt message token, | 
to_interrupt_task mbx, @interrupt_ status) ; 


interrupt _message_token = rq$receive$message 
(to_ interrupt | task mbx, wait forever, 
@dummy_mbx, @interrupt status) ; 


end; 


END INTERRUPT. _TASK; 


GIGI GIO ISIS IIIT AAC) 


/* CONVERT DIGITS is a small procedure for */ 
/* converting a hex number into an ASCII * / 
/* number, with the advance knowledge that the */ 
/* hex number will be less than 99 decimal (in */ 


/* this case, less than 32 decimal). */ 
[RRR ERE RERRERERREKERREKRERERERERERERERERE / 


CONVERT DIGITS: PROCEDURE; 


converted value. first digit ascii mask; 


- converted. value. second _digit = ascii mask; 


= not. done; 
do while done. _flag = not _done; 
value_to convert = value to _convert - 10; 


_/* The problem here is we ee to check for */ 
/* a negative value when we have BYTE values */ 


/* which are, by definition, positive and */ 
 f/* mudulo 256. So we. adapt. by checking for */ 
/* > 200 decimal, which should mean the * / 
/* value has "wrapped" around zero. Tf it * / 
/* has, we can get our previous value back * / 
/* by adding 10. | | */ 


if value to convert < 200 then 
converted ~value. first digit 
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, = converted value.first digit + 1; 
else > ae are 
do; 
value: to convert value to convert + 10; 
converted value. eaeone _digit 
= converted value.second digit + 

~value_ to _convert; 

done flag = done; _ ; 


END CONN ern _DIGITS ;. 


ODAC ISI ISIS ISITE TOTO IU IOI ICI IG IO IE IEE a 


/* SEND STATUS. converts the current frame */ 
/* number into ASCII and stuffs it into the * / 
/* previously initialized status line. Then */ 
/* SEND STATUS sends the status line to the */ 


/* terminal handler and waits for the pegment * / 


/* to be returned. 4 
[LEAST ATERTIE OPI EE TEER ERA ERE AH E YEE 


SEND STATUS: PROCEDURE; 
value _to convert = data segment.this frame number; 
pane Onyere _digits; 


output purEene character (processed _ so far entry) 
= converted value.first digit; 


oe Buffer: character (processed __ so far ener ys) ) 


= converted _value. second digit; 


value to convert = data _segment. frames_ to average; 


call convert _digits; 


output _ buffer. aharac ter: (frames to process entry) 
= converted value.first digit; 


output _ buffer.character (frames __ to _process _ entry+1) 


= converted _value. second “digit; 


call we Seendsmeseage: 
| (th_out mbx, output buffer token, 
return _mbx, Astatus) ; 
output_ purSerS token: = rqSreceive$message 
(return mbx, wait forever, 
@dummy_ mbx,- @status); 


END Sen, US 


OIG IGE IIS ICI UIE IIS TOIT ISIE IOI IOI TEI II II IAT 
/* INPUT DATA selects the fast or slow input */ 
/* handler, initializes the 8253 timer as x / 
/* necessary, and calls the appropriate input */ 
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[BRR RRR KR RRR EREKE RK ERRRRERE REE RRR REAR / 


handler: Please® note the values of the 


intervals selected for sampling are 
scaled by 60/54 so the actual frequency 


*. output of the 128° sample’ FFT. algorithm will 


match: up with the base 10 x axis labels. 


Base 10: doesn't' map’ too well to a binary 


x-axis. that runs. from 1 to 464. 


INPUT DATA: PROCEDURE; 


declare LSB 120Hz interval: literally '058H' 
declare MSB 120Hz interval literally '002H' 
declare “LSB S00Hz_interval’ literally "O78H' 
“declare” MSB_ _600HZ_ Se alae | "000H" 


declare threshold for. 120Hz ° 2 
declare threshold_ for_ 500Hz 


aac tes. a: 39006. _microsecond_ interval 
AS : ge eS sliterally 'OF42H'; 


saree ies Giese literally '5'; 


*, The: 8253° Bimer. is: running’ at 143, 6 Khz, or 
6.5 microseconds per: count. We have’ to 
restart the sampling process precisely, so 


we count down after: the’ ‘interrupt tobe 
Sure we are synchronized. In this case, 
we have a 300 microsecond window after the 
interrupt to get ‘the sample. 300." 
microseconds is roughly ae times (665 


-microseconds, = © 


~e Me Me NO 


it 


declare nucleus allocated stack literally 'OOH' 
declare shift: ‘integer right’. «literally ‘SAL' 


declare 
declare 


software _priority_ reget Q literally 'ooH' 
software _ priority. level. “66 literally '66' 


declare stack size 512 literally '512' 
 <" declare task. _flags. a ar “rd. litetally "QOH' 
~ -@eclare this task: | literally 'OOH' 

‘declare. timer. _mode_ control. -word literally '74H' 


aeciace enable_ _conversion : | literally ae 


me tte Te Me NV Ve BWe WS 


literally 'O22EH'; 
eae, 'O0048H "3 


declare, ee command ae 4 ‘qapenaity ‘O080H'; 


The: first. shina: we do. is: start the conver- 
* sions. “We don't care about the first 
data: since we are going to ignore it. Each 


time we read both bytes of the present 
converted value, we start: the next 
conversion. This initialization will 


cai i the’ Teal ae ty aie 


7. 
ad 
ig 


“output (input_ command). Pee enable_ conversion; 
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251 2 if data SScgwents Sempre interval > 391 then 
252 2 — do; - 
253 3 | output (timer_ mode sontyell _port) 


= timer _mode control word; 
254 3 , » L£ data _segment. sample_ interval 
= a 3906 microsecond interval then 


255 3 do; 
256 4 timer threshold r | 
= threshold for 120Hz; 
257 4 output (fimer<: one _port) 
| = LSB 120HZ_ interval; 
258 4 output (timer one _port) 
= MSB 120Hz interval; 
259 4 end; i os 
else 
260 3 do; 
261 A sso... timer threshold ». | 
. : = threshold __ for S0O0OHZ; . 
202-°°° 423 _ output (timer one _port) 
. | aa = LSB 600Hz interval; 
263 4 output (timer one _ port) 
= MSB _600HZ__ interval; 
264 4 end; 
255 3 first See Loop _ ered. = first loop; 
266 3 if interrupt_ task| flag 
) 2. = interrupt nests eNOS eeneo then 
267 3 do; -_ | 
268 A : ” interrupt _ task - re = rqScreateStask 
| (software _priority_ level 56, 
@interrupt_ task, no data "segment, 
nucleus — aii scaeed stack, 
Scan size alee task _flags, Mstatus) ; 7 
269 4 call roses Chr casanaect . 
| (supervisor job, interrupt task token, 
@(12,'INTERRUPTTSK'), @status) ; 
270 4 interrupt task flag 
= interrupt task created; 
271 4 end; 
272 3 else call rqSenable 
(hardware interrupt level 3, @status); - 
/* Now we wait until the slow handler */ 
/* fills the. URES e Tee Dh ta a * / 
De Soto. Bee Rg hie 8 signal_ interrupt oe rqSreceiveSmessage 


~ (from_ interrupt _ ea DK wait eerie 
@dummy _ mbxX ,». @status) ; gg 8 


/* Tf we get the token, we know the buffer */ | 
/* is full, so we disable level 3 . ES 
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call rq$disable 


(hardware_ interrupt_ level a; @status) ;. 


: ype And return the eoken so ene a 


/* INTERRUPT. _ TASK can enable lower */ 
f/* interrupt levels. | */ 


call rqSsendSmessage 
7 (to interrupt _ task _mbx, 
| signal _ interrupt_ token, 
no _response_ requested, 4status) ; 


/* The fast INPUT handler must sample at 

/* precise intervals that do not allow 

/* variable interrupt latency. Therefore 
/* we raise the priority level to 0--the 

/* highest--and just sample in a polling 

/* fashion until the buffer is filled. 


‘call rqSsetSpriority 


ws 
wld 
a7. 


#7 


e/ 
*/ 


(this task, software _priority_ level 0, 


@status) ; 


call FAST INPUT HANDLER (data segment _ pointer) ; 


call rq$setSpriority 


(this task, sort vene _priority level 44, 


|  @status); 
one ts. Py . 


do = general_ index: 0 to 127; 
data _segment. eanpie (general_ index) 
= shift. integer right x 
: p(aate Segment. Bombe (general _ index), 
: | five _places); 
end; 


do general index = 128 to 255; 
data _segment. sample (general _ pees = OOOOH; 
end; ? 


END INPUT DATA; 


[RRR ERE RRR KRHA ER ER EER ERK / 


/* UPDATE FRAME NUMBER just updates the frame 
/* number parameter on the data segments. 


UPDATE | ‘FRAME. "NUMBER: ‘PROCEDURE; 


oil 
i) 
e 


data ocgment: sample pointer . 
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292 2 if frames received = data _segment.frames to average 
then frames _ received = 0; 
294 2 Ae data segment.reset flag = new fft run then 
295 2 do; 
296 3 frames received = 0; 
297 3 data segment.reset flag = 0; 
298 3 end; 
299 2 frames received = frames received + 1; 
300 2 data segment.this frame number = frames received; 
301 2 END UPDATE FRAME NUMBER; 
[J RRRRRKRERKE RK KEKE KEKE ERE KER KER KKRKEKEKEKREKEKREKKEKK / 
/* INITIALIZE BUFFERS takes care of the usual */ 
/* trivia of setting up the pointers, creating */ 
/* the return mailbox, looking up the terminal */ 
/* handler, and all that other small garbage. */ 
[J RRRKRRRREKEKRERKEREKEREKREKRERKRRREREKEKREREREREREKEREE / 
302 1 INITIALIZE BUFFERS: PROCEDURE; 
303 2 return _mbx = rqScreateSmailbox 
(queue fifo, Astatus); 
304 2 call rqScatalogSobject 
(supervisor job, return _mbx, 
@(9,'I RET MBX'), Astatus) ; 
305 2 from interrupt task mbx = rqScreateSmailbox 
(queue fifo, @status); 
304 2 call rqS$catalogSobject ; 
(supervisor job, from_interrupt_ task mbx, 
@(12,'FM INTSK MBX'), @status) ; 
307: 2 to interrupt task mbx = rqScreateSmailbox 
(queue fifo, @status); 
308 2 call rqS$catalog$object 
: (supervisor job, to_interrupt task mbx, 
@(12,'TO INTSK MBX"), @status) ; 
309 £2 interrupt _message_ token = pac cpegneséeanent 
(size 2 bytes, : @status) ; 
310 2 call rq$catalogSobject 
(supervisor job, interrupt message token, 
@(10,"INTTSK MSG'), @sStatus); 
311 2 interrupt _ task flag | 
= interrupt_ task _not_ created; 
312 2 output buffer token = rq$create$segment 
(size 120 _bytes, 4status) ; 
313 2 call rq$catalogSobject 


(supervisor job, output. buffer token, 
@(10,'I BUFF SEG'), @status) ; 
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314 2 output _buffer pointer values.offset = 0; 
output_ buffer — _pointer ~values.base 
= output buffer token; 


WW 
a 
mn 
No 


315 2. output buffer.function = th write; 
317 2 output buffer.count = 110; 
318 2 do general index = 0 to 4; 
319 3 output | buffer .home chars (general index) 
= cursor home chars (general index); _ 
320 3 end; 
321 do general index = 0 to 21; 


2 | 
322 3 output _ buffer.line index (general_ index) 
= line feed; 


323 3 end; 
324 2 do general index = 22 to 23; 
325 3 output buffer.line index (general index) 
= null; 
326 3 end; 
327 2 do general index = 0 to 78; 
328 3 output _ buffer.character (general index) 
= input_ status _line (general _index) ; 
329 3 end; : 
330 2 root ORs token = rqSgetStaskStokens 
(rootjob, @status) ; 
331 2 th out_mbx = rqSlookupSobject 
(root _job_ token, @(11,'ROTHNORMOUT'), 
wait _forever, @status) ; 
332 2 frames received = 0;. 
333 2 END INITIALIZE BUFFERS; 
[J RRRRRKRRERKRKEREKR ERE RK RRR ERKRREKRERREERRREKEEKEEEEKRKE / 
/* The actual INPUT TASK begins here. It * / 
/* initializes the buffers to begin things, */ 
/* then waits forever for the FFT sample */ 


/* segment. It then samples the data, fills */ 
/* the FFT data segment, and sends it to the */ 
/* FFT TASK. The INPUT TASK then updates its */. 


/* status line, sends it to the terminal * / 
/* handler, and returns to the mailbox to * / 
/* wait forever. * / 


ESTEE Tee CCE TECETETECTCTSTCCTTCE TET ESET TT TCG, 


334 1 INPUT TASK: | PROCEDURE PUBLIC; 

3352 call initialize buffers; 

336 2 data segment pointer _values.offset = 0; 
337 2 do forever; _ 
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/* Wait forever for an FFT data segment at */ 
/* the to_input_mbx. */ 


338 3 data segment token = rqSreceiveSmessage 
~ (to input_mbx, wait forever, 
@dummy mbx, status) ; 
339 3 data segment pointer values.base 
a _ = data_segment_token; 


340 3 call update frame number; 

341 3 call input data; 

342 3 call send status; 

343 3 call rqSsendSmessage 
(to fft_mbx, data _segment_token, 
no_response requested, @status) ; 

344 3 end; 

345 2 END INPUT TASK; 

346 l END INPUT TASK MODULE; 


MODULE INFORMATION: 


CODE AREA SIZE 070BH 1803D 


CONSTANT AREA SIZE = OOOOH OD 
VARIABLE AREA SIZE = 0036H 54D 
MAXIMUM STACK SIZE = 


00 2AH 42D 
754 LINES READ | 
0 PROGRAM ERROR (S) 

END OF PL/M-86 COMPILATION 
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_MCS-86 MACRO ASSEMBLER FSTINP .... « 
ISIS-II MCS-86 MACRO ASSEMBLER V2.1 “ASSEMBLY. OF MODULE FSTINP 
OBJECT MODULE PLACED IN :F1:FSTINP.OBJ | 
ASSEMBLER INVOKED BY: . asmss. rElrfstinp.ags ..- 


LOC OBJ LINE ~ SOURCE: 


1 : "HERERO EIU D EOD IDIOTS IIIA 
2 ; 
3 ; FAST..INPUT HANDLER for. APNOTE 110, 
OCTOBER 1980. - 
4 ; 
5 ; FAST INPUT HANDLER ‘is. an assembler routine. 
that runs at priority 
6 ; level 0 and simply. drives an analog to 
bah .. digital. convertor and 
ys y .stuffs the samples into a data segment until 
2 all of the samples 
8 ; have been taken. FAST INPUT HANDLER has 
passed to it the address 
9 : of the data segment, _ ‘in which the offset is 
known to be zero. ? 
10 : FAST INPUT HANDLER. returns nothing to the > 
calling routine. 
ll : 
12 ; FAST INPUT HANDLER prouTeee the pEOpey aes 
for sampling at a 
13 ; 39, 78, and aay microsecond intervals using 
timed: Joops of. | 
14 ; software instructions. In “order to provide 
an FFT without: large . 
1s ; amounts. of jitter, the sample intervals must 
be uniform in time. 
16 ; 1iIRMX 86 cannot guarantee this uniformity aus 
to its real time = |... ws | : 
ae ; design, so this routine Pee semorers 
control of the processor 
18 : for the (39 times 128) 4.9 milliseconds or 
(78 times 128) 9.9 
19 ; or (391 times 128) 50 milliseconds required 
to complete a frame 
20 ; of 128 samples. 
2 : 
22 ; iAPX 86 register useage is the following: 
23 : 
24 ; AX - general BX — stack index 
25 : CX - loop delay counter DX - sample value 
26 : 
27 : BP - stack SP - stack 
28 ; DI - offset index into FFT SI - not used 
29 ; data segment 
30 : 
31 : DS - base for FFT data ES - not. used 
32 segment 
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70 


at 


72 


33 
34 
35 
36 
37 
38 
39 
40 
0080 41 
0081 42 
OO0E 43 
0002 44 
0002 45 
Q10E 46 
: ae 
48 
see 49 
50 
0000 2??? 51 
52 
ee 53 
54 
55 
Pee 56 
57 
0000 (20 58 
0000 
) 
59 
ee 60 
61 
62: 
Sere 63 
64 
0000 65 
56 
0000 1E 67 
0001 55. 48 
0002 8BEC 69 
0004 SE5E0A 
0007 BFO200 
OOOA 8B05 
000C BFOEOO 
OOOF 3D2700 
0012 740E 
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; 
; 
; 
; ate, 3 
ASSUME DS:FAST INPUT DATA, SS:STACK, 
CS:FAST INPUT CODE, ES:NOTHING 


; 
PUBLIC FAST INPUT HANDLER 


; 
SAMPLE LSB - EQU ~=-0080H 
SAMPLE MSB - EQU 0081H 
FIRST PASS EQU 14 
SAMPLE INCREMENT EQU 2 
SAMPLE INTERVAL EQU 2 
SAMPLE MAX _ — -EQU 270 
aa | : 
FAST INPUT DATA SEGMENT WORD 
PUBLIC ‘DATA! 
; | | . 
LOOP VALUE DW ? 
Bt ' 
FAST INPUT DATA “ENDS 
; . 
STACK : SEGMENT STACK 'STACK' 
; a | 
DW 20 DUP (0) 
STACK | ENDS 
; , ’ 
FAST INPUT CODE SEGMENT PARA 
- PUBLIC 'CODE' 
; , 
FAST INPUT HANDLER PROC FAR 
: | 
PUSH DS 
PUSH BP 


; SAVE BP IN STACK 
MOV BP, SP | 
; SET BP TO STACK POINTER 
MOV DS, fBP + 10] _ 
: PUT BASE OF SAMPLE SEGMENT IN DS 


MOV ODI, SAMPLE INTERVAL 


; DX IS USED TO INDEX INTO THE DATA SEGMENT — 
MOV AX, DS: [DI] | 
; SET AX TO SAMPLE INTERVAL PARAMETER 
MOV DI, FIRST _PASS — 
; RESET DI TO FIRST SAMPLE - 14 
CMP AX, 39 2 
; IF AX = 39, SET LOOP VALUE TO 9--LOOP 
JZ SET 39 US 7 
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; TAKES ABOUT 3 US PER DECREMENT 


-3D4E00 76 .CMP AX,.78. 


; IF AX = 718, SET LOOP VALUE TO 22--BASIC 


7412 77 JZ SET 78 US 


-. g CYCLE7IS713 US, PLUS (22x 3) = 79 US 

C70600007E00 R78 MOV .LOOP VALUE, 126 

| ; 391 IS ONLY ONE LEFT-13 + (126X3) 

— | = 39]. 

EB1090 79  JMP INPUT LOOP | 
C70600000900 R 80 SET 39 US: ~-MOV LOOP VALUE, Q 

| ; TIMING IS BY. SOFTWARE--SET 

DELAY COUNT | 


EB0790 81 . JMP INPUT LOOP. e Ne 
C70600001600 R 82 SET 78 _US:.. MOV. LOOP VALUE, 223... 
SBOE0000 R 83. INPUT LOOP: MOV CX, LOOP VALUE 

7 ; USE CX TO KEEP TRACK OF. DELAY 
E480 84 IN AL, SAMPLE LSB 


: ; SET AL TO LSB OF INPUT SAMPLE 
8AD0 85 MOV DL, AL 
; PUT THE LSB IN DL (8 BIT XFERS ONLY) 
E481 86 IN AL, SAMPLE MSB 
; SET AL TO MSB OF INPUT SAMPLE 
87 ; THIS RESTARTS SAMPLE PROCESS 
SAFO 88 MOV DH, AL 
; PUT AL IN DH TO COMPLETE THE VALUE. 


83FFOE 89 CMP DI, FIRST PASS 


| ; WE WANT TO SKIP THE FIRST SAMPLE 
7408 90 Jz SKIP INPUT 


2 83C702 91 ADD DI, SAMPLE INCREMENT 


; INCREMENT DI BY 2 
8915 92 MOV DS:fDI], DX 
; PUT SAMPLE DATA IN SEGMENT) 
EB0990 93 JMP DELAY 
; AND JUMP TO SOFTWARE DELAY LOOP 
83C702 94 SKIP INPUT: ADD DI, SAMPLE INCREMENT 
; INCREMENT DI BY 2 - 


°0 95 NOP 

fi ; AND NOP FIVE TIMES FOR EVEN TIMING © 

90 96 NOP : - 
' 90 97 NOP ; 

90 98 NOP : 

90 99 NOP : 

90 100 DELAY: NOP | 


;. THIS NOP ADDS 3 CLOCKS PER. DECREMENT 
EOFD 101 \LOOPNZ DELAY 
; DEC CX AND LOOP--1. 5. US PER DECREMENT 
S1FFOEO1 102 CMP ODI, SAMPLE MAX _.. 
: 3 ; COMPARE DI TO SEE IF .WE ARE DONE 
75D6 103 JNE INPUT LOOP 
Rs | ; IF NOT, GO BACK FOR ANOTHER SAMPLE 
5D 104 POP BP 


- 3 OTHERWISE POP BP, ‘DS, AND RETURN 
1F 105 POP DS | 3 
CA0400 106 RET 4H : 
107 ~~; 
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108 FAST INPUT HANDLER ENDP 

— 109 : a | 

———= 110 FAST INPUT CODE ENDS 
m = Sell - ~ 

112 © END 


ASSEMBLY COMPLETE, NO ERRORS FOUND 
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Both the RAM and ROM-based configurations will be: 


discussed in this appendix. They are essentially identical 


processes. In either case, the first step is to definea map: 


of system memory. Once the map is known, the follow- 
ing sequence is suggested for locating code in memory: 


1) Reserve memory 0H to 03FFH for the Nucleus in- 


terrupt vector. 


2) If the system is RAM based and the code is loaded 
by the iSBC 957A Monitor, reserve locations 
03FFH to 07FFH for the monitor’s use. 


3) Configure each of the necessary portions of the 
iRMX 86 Operating System and locate them se- 
quentially in memory. 


4) For a RAM-based development system, allow 2K of 
RAM for the system Root Job. Placing the Root 
Job after the portions of the iRMX 86 Operating 
System, which are relatively fixed in size during 
development, and before the development code will 
give the Root Job a fixed address. This will prevent 
having to move the Root Job and reconfigure the 
system when the development code grows. For final 

-EPROM-based systems, the Root Job should be 
placed after the development code. 


ww 


5 Link and locate each of the application code mod- 


ules sequentially in memory. 


~~ 


6 


wes’ 


Define the RAM available to the system. 


7) Define memory NOT available to the system. This 
includes application code, EPROM, and non- 
existent memory within the 1 megabyte address 
space. 


8) Create the configuration file using the address maps 
produced by the locate steps and the memory map 
defined in steps 6 and 7. 


9 


ww 


Create the Root Job from this configuration file. 
10) Load and test the system in RAM. | 


11) If the system has been fully debugged, load the code 


into EPROM and test the final system. 


V__Z 


The above steps are necessary for both the RAM devel- 
opment system and the final EPROM system. Convert- 
ing this application from RAM to EPROM requires re- 
configuring the Nucleus to include only those systems 
calls required by the application, substituting the Ter- 
minal Handler Job for the Debugger Job, removing any 
remaining system calls to catalog objects for debugging, 
and remapping the system to the EPROM address 
space. The memory maps for the development and final 
application are shown in Figures C-1 and C-2. 


MODULE. ADDRESS 


: FFFFFH 
(RESERVED) 
RESET VECTOR 


iSBC 957A MONITOR EPROM 


FFFFOH 
FDOOOH 


NON. 
EXISTENT 


20000H 
OFFFFH 
OED50H 
0EC10H 
OEBO7H 
OCOBOH 
OBACOH 
05330H 
0000H 


000H 
0H 


SYSTEM RAM 
EXPANSION 
APPLICATION DATA 
EXPANSION 
APPLICATION CODE 
ROOT JOB 
DEBUGGER 
NUCLEUS 
iSBC 957A MONITOR 
INTERRUPT VECTOR 


Figure C-1. Development System Memory Map 


MODULE | ADDRESS 
(RESERVED) nrneee 
RESET VECTOR 
UNUSED EPROM 
ROOT JOB 
APPLICATION CODE 
TERMINAL HANDLER CODE 
NUCLEUS CODE 


FFFFOH 
FF5COH © 
FD3D0H 
FCAOOH 
F8000H 


NON- 
EXISTENT 


04000H 


SYSTEM RAM 
: OB90H 


ROOT JOB DATA 
APPLICATION DATA 
TERMINAL HANDLER DATA 
NUCLEUS STACK 
NUCLEUS DATA 
INTERRUPT VECTOR 


OB80H 
OAS58H 
0990H 
0800H 
400H 
0H 


Figure C-2. Final System Memory Map 


System configuration is a straightforward but exacting 
process. As with any such processes, there are some 
hints that can make development easier. In addition to 
care in locating the Root Job in memory, ‘users should 
fix the initialization job entry point and the data RAM 
addresses. 
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The Intel PL/M 86 programming language does not 
allow a procedure to be used until after it has been de- 
clared. This requires the initialization procedure to be 
declared after all the other procedures. Since the initial- 
ization is last, changing the other procedures will change 
the location of the initialization procedure. If the system 
entry point changes, the system must be reconfigured. 
The moving entry point can be circumvented by writing 
a separate initialization task. The Root Job will create 
only the initialization task which will then initialize the 
system jobs. The initialization task entry point is fixed 
by linking it ahead of the other application tasks and by 
not changing the initialization task during dvelopment. 
The actual system entry points will be bound to the ini- 
tialization task during linking and locating. The linking 
and locating steps are a natural consequence of chang- 
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ing the application code, so binding the fixed system en- 
try point is done automatically during development. 
The fixed initialization task entry point is used in the 
configuration file, giving the Root Job an unchanging 
system entry point. 


The remaining moving target during development is the 
RAM area for data and stack use. If the data and stack 
RAM is located before or after the application code, 
with enough extra memory in between for growth dur- 
ing development, the data and stack locations can stay 
constant. Fixing both the application entry point and 
the locations of the stack and data segments will allow 
development of the application code to proceed without 
requiring frequent reconfigurations. 


2-301 AFN-01931A 


intel ARTICLE — AR-ad 


REPRINT 


July 1977 


2-303 AFN-01931 A 


Single-board microcomputers offer hardware cost-effectiveness for 
implementing many real-time systems. A compatible, resident, real- 
time executive program provides savings in software development 


An Integral Real-Time Executive 
For Microcomputers 


Kenneth Burgett and Edward F. O'Neil 


Intel Corporation _ 
Santa Clara, California 


Single-board computers, or microcomputers, that contain 
central processor, read-write and programmable read- 
only memory, real-time clock, interrupts, and serial and 
parallel input/output all on one printed circuit board, 
have made feasible a whole spectrum of applications 
which previously could not be economically justified. 
These microcomputers have also opened up a range of 
‘applications where the high functional density of large- 
scale integration provides advantages over previous solu- 
tions such as hardwired logic or ‘relatively expensive 
minicomputers. While microcomputers readily solve hard- 
ware requirements, software for single-board computer 
applications with real-time characteristics. (which are 
in the majority) has until now been generated individu- 
ally for each application. 

The Intel RMX/80* Real-Time Multi-Tasking Execu- 


_ tive simplifies real-time application software development, 


and at the same time furnishes capabilities optimized for. 
_ the microcomputer environment. It provides the means to’ 


concurrently monitor and control multiple external events 
‘that occur asynchronously in real-time. The program 
_ framework allows system builders to immediately imple- 
ment software for their particular applications, and to 
avoid specific details of system interaction. 

Major functions of the executive include system re- 
source access based on task priority, intertask communi- 
cation, interrupt driven device control, real-time clock 
control, and interrupt handling. In combination, these 
functions eliminate the need to implement detailed real- 
time coordination for specific applications. 

Previously, two alternative software approaches were 
used to solve microcomputer applications. First, many 


designers created their own operating executive, indi- 
vidually tailored for each application. Obviously, this 
approach was expensive and time-consuming. The second 
approach was to use a minicomputer executive which had 
been adapted to a microcomputer. Since this software 
was designed for a different processing environment and 
then ‘“‘stripped down,” it suffered from major inad-. 
equacies when executed on microcomputers. The alterna- 
tive, RMX/80, has been designed specifically to provide 
a general-purpose real-time executive tailored to Intel 
SBC 80 and System 80 microcomputers. 


| Real-Time System Requirements 


All ‘software design approaches for use in real-time ap- 


plications include capability for concurrence, priority, 
and synchronization/communication. 


~- Concurrenee—Real- time systems monitor and control 
events which are occurring asynchronously in the physi- 


cal ‘world. Microconiputer software does not know ex- 
actly. ‘when external: events will occur; however, it must 
be prepared to perform the necessary processing upon 
demand, whenever the events:.actually do occur. Typical- 
ly, interrupts are used to inform the microcomputer that 
an event has occurred. At interrupt time, system control 
software determines what processing to perform, as well 
as the relative sequence in which processing must take. 
place. z é 


*RMX/80™ is a registered tradémark of the Intel Corp, Santa 
Clara, Calif. - 


Reprinted from COMPUTER DESIGN, July 1977. Copyright Cahners Publishing Co.,Inc. 1977. All rights reserved. 


2-304 — 


AFN-01931A 


Programs related to external events are processed in 
an interleaved manner based on interrupt occurrence 
and priority. For instance, one routine is executing when 
an interrupt activates, signaling that a higher priority 
event has occurred. At this point, the routine related to 
the priority interrupt is started, while execution of the 
less important routine is discontinued temporarily. When 
the more important routine is completed, or temporarily 
halted for some other reason, execution of the less im- 
portant routine is resumed. In this manner, multiple pro- 
grams execute concurrently in an interleaved fashion. 
Priority—In a real-time environment, certain events re- 
quire more immediate attention than others because of 
their significance within the physical world. Immediacy 
is relative to other processing, and is determined by ap- 
plication requirements. The concept of immediacy or pri- 
ority, however, is common throughout all real-time micro- 
computer applications. In priority-based systems, the most 
important program (one that is not waiting for some 
physical or logical reason) is the one executing. 

A classic illustration of program priority in real-time 

systems is found in the area of plant control. When the 
plant begins to fail in a nonrecoverable manner, it is 
imperative that the plant be shut down as quickly as 
possible. For this reason, shutdown processing takes 
priority over all other system demands. Software pri- 
ority enforces this Hardware concept of physical opera- 
tional events. 
Syachroniaon Comuunicaon— nee: common sim- 
ilarity in most real-time systems is the need for synchro- 
nization between various events in the physical world 
which are under microcomputer control. Synchroniza- 
tion is defined as the process whereby one event may 
cause one or more other events to occur. Communication 
is the process through which data are sent between in- 
put/output (1/0) devices or programs and other pro- 
grams within the microcomputer system. 

An example of the need for synchronization and com- 
munication is a microcomputer system for weighing and 
stamping packages. One part of the system weighs the 
package, calculates pricing, and releases the package 
onto a conveyor belt. Price and weight data are com- 
municated to another part of the system which stamps 
the data onto the package after it arrives at a sensor 
station. Synchronization is demonstrated by the occur- 
rence of one event—package arrival—causing another 
event—package compete occur. 


Compatible Benefits 


To satisfy real-time microcomputer software’. require- 
ments, the RMX/80 Real-Time Executive software (Fig 
1) was designed. This program differs from existing 
software systems by offering capabilities directly re- 
lated to the single-board microcomputer environment 
in which it operates. These capabilities have two major 
bottom-line benefits compared with equivalent minicom- 
puter systems. First, the executive code is compact 
enough to allow a large number of real-time applications 
to. be processed on a single microcomputer board. To 
accomplish this capability, its nucleus is. optimized to 
reside in less than 2k bytes [ie, in a single 16k program- 
mable read-only memory (p/ROM) J, thereby allowing up 
to 1OK of onboard memory for application-related soft- 
ware and storage. 


Fig 1 A typical RMX/80 system. Mul- 
tiple tasks control a given application. 
Nucleus controls execution of both 
user and executive tasks through 
task-to-task communication, real-time 
clock, priority resolution, and inter- 
-rupt- handling facilities. All tasks with- 
in an RMX/80-based application use 
at least some of these capabilities; 
other optional executive tasks include 
debugger, free-space manager, and 
device control for operator’s console, 
diskette file system, analog subsys- 
tems, and high speed mathematics 
unit 


Second, the executive may be p/ROM.- resident. When 
the microcomputer system is powered on, the software 
system (executive plus application programs) is. auto- 
matically initialized and begins execution of the highest 
priority application task. Typical major real-time execu- 
tives, however, are totally random-access read-write semi- 
conductor memory (RAM)-resident, which means they 
must be initialized (booted) from a peripheral device, 
such as diskette, | cassette, or communications line, into 
microcomputer memory. The need for peripheral devices 
significantly increases the total cost of traditional real. 
time executive-based solutions. 


Sample Application 


Functioning asa real- ‘inie executive for microcomputers, 
this software system provides facilities: for orderly .con- 
trol and monitoring of asynchronously occurring <ex- 
ternal events. Although. these events may differ: widely 
from application to application, facilities are adaptable 
to: nearly all processes. where the microcomputers are 
used, including process and machine control, test and 
measurement, data communications, and specialized on- 
line data processing. applications (where one or more 
terminals access: diskette-based data). The executive. is 
particularly. useful in dedicated low cost applications 
which were not economically feasible before the advent 
of microcomputers. For example, consider. the require- 
ment of gas pump control.in a service station (Fig 2). 

In this. station,.-a microcomputer system operating. 
with RMX/80 concurrently monitors and controls mul- 
tiple gas pumps, and sends price and volume informa- 
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tion to one central location. At the same time, informa: 
tion about station operation. is-being transmitted over a 
communications line to: a: fegional. computer. ‘ 
_ Individual tasks are ‘developed independently to mea- 
sure gas flow,” -calculaté. and display. price information, 
transfer data.to the centr I computer, and monitor levels 
of gasoline in underground - storage. All this processing 
takes place concurrently: ‘ander. program ‘control. (Credit 


verification: - ‘charge slip” printing, and billing can also 


be controlled’ by additional software tasks.)’. 

Efficient gas station operation. demands. that the hard: 
ware/software system be highly reliable. The compatible 
benefits of compact code, p/ROM residency, and self- 
initialization on a single-board microcomputer system all 
combine to ensure functional integrity. 


Software Structure 


RMX/80 simplifies the effoit for = ievlobhie: a real- time 
system, first, by providing many commonly required 
software functions. Second,. its software structure pro- 
motes efficient program development. Programmers who 
are familiar with structured programming will find task 
orientation both natural and. easy to use. 

_ Tasking means that a larger program. is divided into 
a number of. smaller, logically independent programs or 
tasks. The key is to identify functions that may occur 
concurrently. For example, consider’ the ‘tasks required 
for a terminal handler—real-time asynchronous I/O be- 
tween an: operator’s CRT terminal and the-executive. - 


Input Handler Task—One task must be ready to accept 
a data character from the terminal at any time. This is 
done by responding to-an: interrupt signal from the 


terminal and then accepting the data character. The’ task. 


immediately passes the input character ‘to: a subsequent 
task® ‘automatically and then: goes back to: wait for an- 
other interrupt. - a . 


Line Buffer Task—As dhiaractsie are received from the 
input handler they must be placed into a buffer to form 
a line. Eventually, the buffer will be filled or the logical 
end- of- line will be signaled by. a carriage return. char- 
acter. At this point, the line buffer must be. sent. to. some 
other task for processing. | 


Echo Driver Task—For a full- digelene eeuitaal it is 
necessary to return each input character to the ‘ceiminal 
for display on the CRT screen.. This: task: waits for.:a 
character, which could be sent by either the line buffer 
or input handler task, and: then sends the character. to 
the terminal. It then waits for the next character. : 

Note that input handler and echo driver are Sescthed 
as waiting for an event. Within: the RMX/80, that -is 
literally the case. While they wait, however, system. re- 
sources are’ available for other tasks, such as that of the 
line buffer. Thus, effective processing: may occur con- 
currently. with necessary’ waiting” periods. Notice also 
that’ a number ‘of other. tasks. may: also be active within 
the system. In fact, the greater the number of tasks run- 
ning concurrently, the more: effectively: ‘System: resources 
are used. ‘Concurrent: operation eliminates many ‘time 
wasting procedures from’ a-real-time’ system.» For: ex- 
ample, the executive can eliminate “the. need: for: ‘many 
timing loops where the processor simply ‘executes’ a: ‘no- 
operation instruction ‘: fepeatedly- eis waiting” ‘for: an 
event to. occur. ene ch, Gee ree ie ae ae 


eae S 
pe 


d 


TO REGIONAL. 
“COMPUTER VIA - 
: ae Rone? LINES 


ai DISPLAY PERE ee of feo. 
TERMINAL a pit 


‘Fig 2 ‘Microcomputer contro! for gas pump automa- 
tion. In this’ example, executive-based system simul- 
taneously controls two pumps, displays: information on |. 

. Operator’s .console, and.. communicates with regional. .. 

_ computer. At a given time, more or. fewer functions 

"could be operating © concurrently. System expansion — 
can’ be: easily eecompllened: oy agding ‘tasks’ and ~ 
moquige perOwere: . 


"Within the executive, ere sat Swale. are lexically in- 
dependent, they. are also physically independent, actually 
contending with each other for the use of the processor 
and other system resources. The executive resolves this 
contention based on the..priority. of each. task. : 

. In, the terminal handler example, it is clear that the 
input handler must have highest priority, since accept- 
able performance cannot tolerate the loss of data. Second 


_highest.priority is given to the.echo driver, so that data 


appearing onthe screen remain. coordinated with the 
input.. Lowest priority .goes to the line buffer, since that 
function. does not. depend directly. on an. external asyn- 
chronous event. There. are. no, particular real-time con- 
straints.on the. line buffer. as long as the input char- 
acters. are. eventually. processed. , 

It..is, possible. to write the. entire: terminal. handler: as 
a single large task. instead of..as_ several smaller tasks, 
However, consideration must be given other high priority 
tasks . operating within the, system which may not be 
able. to gain control while: a low priority portion of the 
terminal handler, such as the line buffer. task, is execut- 
ing. Therefore, tasks. assigned as. high. priority are gen- 
erally kept as short as possible. If. the terminal handler 
were written as one large task, it could tie up the entire 
processing system for a relatively trivial function. 


Task States ~ 


Two tke states hive ‘Licks Pies meee and wait- 
ing. A running task: is always the task::which currently 
has‘ the highest. priority and is not suspended or waiting. 
A: waiting: ‘task remains in the wait state until it ‘receives 
a message or an interrupt for which it is waiting or until 
a specified: time period: has passed. The wait period c can 
be timed”:using the system clock. - 

- A running task‘ may ‘suspend itself on some ier tail 
in the: system. A suspended’ task cannot begin ‘execution 
again.-until some running® task ‘orders ‘it’ to resume.’ As 
an example, a password routine might’ temporarily ‘sus- 
pend the echo driver of the terminal handler so that’ the 
password is not displayed. (The password routine must 
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fad’ Fig 3 System message exchanges. 


In intertask communication (a) task 
1 sends a message to an exchange, 
where it is held until task 2 requests 
message via accept. In_ intertask 
(b) communication with delay (b), task 
INTERTASK COMMUNICATION INTERTASK COMMUNICATION WITH DELAY 2 waits for a message from task 1 
. until data are available or until a 
RMX/80 RMX/80 certain time period has_ passed, 
whichever occurs first. In task con- 
trol (c), any task may suspend or 
resume any other task. In interrupt 
processing (d), an I/O interrupt is 
transformed into a message that task 
1 receives via a wait command. 
Task 1 then performs appropriate 
interrupt processing 


(d) 
TASK CONTROL INTERRUPT PROCESSING 


remove the password from the line buffer, or it will be 
displayed as soon as execution of the echo driver is 
resumed. ) 

A task may also be in the ready state. A eats task is 
one that would be running except that a task with higher 
priority temporarily controls the system resources. The 


P/ROM-BASED SEGMENTS - | RAM- BASED SEGMENTS’ executive maintains a list of all tasks that are ready to 
‘ RMR BO NUCLEUS : “SYSTEM STORAGE _ run. The next task to be run is always the _ as 
the highest priority in the ready list. , 
i” Device CONTROL The running task relinquishes its control of the sys- 
TASKS ‘FREE SPACE 
nee: | : ; tem by 
smug FREE SPACE 
eee RANAGER | (1) Putting itself into a wait state 
USER TASK 1 fe 
- se 3 | (2) Suspending itself | 
| | | | | (3) Sending a message to a higher priority task, which 
if it has the highest current. priority, becomes the run- 
Fig 4 Memory utilization. RMX/80 nucleus, de- ning task 
vice control task, and free- -space allocation mod- 
ules are linked with user tasks to form a real-time (4) Being preempted by an interrupt to a higher pri- 
- system. Although executive may be RAM-resident, ority task 
it is designed to reside in p/ROM and uses RAM 
only for temporary storage and free space. User | In the case of an interrupt, the executive saves the 
tasks are provided by user at generation time. status (contents of registers, etc) of the interrupted task 


RAM may be used by RMX/80 and all associated 


tasks for temporary storage, including stack. so that it will be restarted correctly. 


Message Exchanges 


Tasks communicate with each other by sending messages 
(Fig 3): The sending task constructs the message to be 
sent in RAM or uses a previously assembled ‘message. 
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Fig 5 Consumer task flow. 
Consumer task performs ini- 
tialization and then drops into 
cyclic loop, alternately waiting 
for messages, performing func- 
tions requested by message, 
and sending an acknowledge- 
ment in form of a response 
message 


The sending task then issues a SEND command that posts 
the address of the message at an exchange. 

An exchange is simply a set of lists maintained by the 
executive. The first list contains the addresses of messages 
available at that exchange. The second list consists of a 
list of tasks that are waiting for messages at that ex- 
change. When a task enters a wait state, it specifies the 
exchange where it expects eventually to find a message. 
The task may wait indefinitely, or it may specify that it 
will only wait. a specific period of time before resuming 
execution. rae 

Messages, together with the exchange mechanism, pro- 
vide for automatic intertask communication and also for 
task synchronization. For example, a message to a par- 
ticular task may specify that the task is to send a re- 
sponse to a certain exchange. Thus, the original task 
may request an acknowledgement response to its mes- 
sage, or it may specify that a message is to be sent to 
a third task. RMX/80 treats interrupts like messages, 
the only difference being that interrupts have their own 
set of exchanges. 

Note that the sending and receiving of messages classi- 
fies tasks into two types—message consumers and mes- 
sage producers. A consumer task waits for a message, 
performs an action based on the message, and then 
returns to the wait state until another message is. re- 
ceived. A producer task initiates its function by sending 


a message to another task, waits for a response, and then - 


sends another message. Figs 5 and 6 graphically illustrate 
the processing within these two tasks. The distinction be- 


TASK ENTRY POINT 


INITIALIZE TASK 


PERFORM FUNCTION 


INITIALIZE OPERATION 
(SEND MESSAGE) 


WAIT FOR RESPONSE 


Fig 6 Producer task _ flow. 
Producer processing flow is 
opposite to that of consumer 
task. Instead of passively re- 
acting to requests from other 
tasks, producer task issues re- 
quests to which other tasks 
must respond 


tween consumer and producer tasks is relative since many 
tasks act as both consumer and producer. 


Executive Modules 


RMX/80 is supplied as a library of relocatable and link- 
able modules. These modules are added selectively as 
required when the user-supplied ‘tasks are passed through 
the link program. Only modules actually requested by 
the application are linked in. For example, if the appli- 
cation program does not specify use of the free-space 
manager, that module is not linked into the system. 
One module, the nucleus, provides basic capabilities 
(concurrence, priority, and synchronization/communi- 
cation) found in all real-time systems. Additional, op- 
tional modules may be configured with user programs 
(tasks) to form a complete application software system. 
These modules include: . 
Terminal handler—Providing real-time asynchronous 
I/O between an operator’s terminal and tasks running 
under the RMX/80 executive, the handler offers a line- 
edit feature similar to that of Isis-1 and an. additional 
type-ahead facility. (1sIs-11 is the supervisory system 
used on the Intellec Development System.) 
Free-space manager—This module maintains a pool of 
free RAM and allocates memory out of the pool upon 
request from a task. In addition, the manager reclaims 
memory and returns it to the pool when it is no longer 
needed. — 
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Debugger—Designed specifically for debugging soft- 
ware running under the RMX/80 executive, the debugger 
is used by linking it to an application program or task. 
Thus, it can be run directly from the single-board com- 
puter’s memory. In addition, an in-circuit emulator, 
such as ICE-80, can be used to load and execute the 
debugger, providing all resources of the Intellec de- 
velopment system to simplify debugging effort. 


Analog interface handlers—Consisting of RMX/80 tasks, 
these handlers provide real-time control for SBC 711, 
724, and 732 systems. 


Diskette file systems—Giving RMX/80 users diskette 
file management capabilities, the diskette driver allows 
users to load tasks into the system and to create, access, 
and delete files in a real-time environment without dis- 
rupting normal processing. All file formats are compatible 
with tsis-11 for both single and double density systems. 


In addition to application program module or task 
requirements, the user also supplies a set of generation 
parameters. These parameters are a set of tables that 
inform the executive of the number of tasks and ex- 
changes in the system. Fig 7 illustrates the system gener- 
ation process. 


Summary 


The significance of RMX/80 to software design parallels 
the significance of the single-board computer to hard- 
ware design. Microcomputers allow designers without ex- 
tensive experience in digital systems to bring computer 
processing power into their applications. Similarly, the 
executive relieves the hardware designer of much soft- 
ware design required for real-time applications. Designed 
to facilitate growth, since new software needed to support 
hardware expansions can be supported easily by the ad- 
dition of new tasks, this executive also substantially re- 


Fig 7 Target microcomputer system. 
Configuration parameters are linked 
together with appropriate RMX/80 and 
user task modules. Resulting program 
is then transferred to its target SBC 
80 system via programmed p/ROMs 
or is debugged using in-circuit emula- 
tion and then transferred 


duces recurring costs because it requires a minimum of 
memory and does not require peripheral bootstrap load- 
ing devices. RMX/80 results in economical, shorter, and 
more flexible software development efforts when design- 
ing, building, and verifying real-time user applications. 
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PRODUCT ANNOUNCEMENT 


‘\ Introducing the RMX/86" realtime, 
multitasking, 16-bit operating system 


“‘Now we have a situation in which electronic intelligence is spreading to more and more 
places, and in addition, the application sophistication at each of these places is growing as well. 
So, when we multiply what it takes to program all the new microcomputer products so that 
they can be applied, and calculate what that means in terms of how many computer program- 
mers will be needed by 1990, we come out with a requirement for over one million computer 
programmers!’’ Excerpted from a speech by Andrew S. Grove, President, Intel Corporation, 
given before the New York Society of Security Analysts, January 24, 1980. 


S production teéhbologies on as VLSI (Very 


increasingly complex application problems has creat- 
ed a crisis in software. A partial solution to the pro- 
grammer shortage would be the creation of ‘‘building 
blocks”’ 


Large Scale Integration] proliferate— with 7 
their greater levels of density—the use of 
low-cost microcomputer hardware to solve. 


for system development. It is this*modular, :. 


ponents. Such systems when needed in OEM micro- 
computer applications, pose problems—rarely can an 
OEM afford man-years of effort to develop the intimate 
familiarity with the hardware that’s needed to design 
executive software. But with Intel’s RMX/86 system he 
won't have to. 

In addition, this second-generation 16-bit system adds 
error handling flexible command-line decode, and other 
advanced OS capabilities to previous options available 
on the mature RMX/80 package. 

All real-time multitasking systems require executive 
software to manage the resources shared by the pro- 
grams (CPU time, memory and I/O], respond to inter- 
rupts and then allocate the resources according to 
established priorities. Normally, these functions are 
intermingled in an OS with higher-level system func- 
tions that often prove superfluous in microcomputer ap- 
plications. 

The RMX/86 package combines all those required 
executive functions in a single module, called the 
nucleus. Other modules in the package tailor the execu- 
tive system to its application by adding higher-level 
operating system functions such as disk-file systems. 
The application programs and optional modules con- 
nect to the nucleus with simple software interfaces. 

Since the nucleus is essentially open-ended, it serves 


~,as the software foundation for expanding both higher- 
‘level operating system functions and varieties of appli- 
“cation programs. Although most microcomputer appli- 


cations are dedicated, many do require such higher-level 
capabilities. 


building block concept upon which the’ RMX/86 }6 Op: i 


erating System is constructed. 


The RMX/86"™ operating system 


This modular operating system for Intel 16-bit 
microcomputers allows custom operating systems to be 


assembled largely from off-the-shelf software com-_ 


2-312 


. The OEM way 


The Sere approach to system software fits in with 


i the way most OEMs (and high-volume end users] apply 


‘single-board computers. They generally start with a 
minimum amount of hardware marketed at the lowest 
cost possible. Then, when their users are fully utilizing 
the original functions and are willing to buy more, the 
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RMX/86™ 


The RMX/86 Nucleus is the heart of the operating system and is 
surrounded by application, human interface and input/output 
facilities. 


OEM adds functionality by increasing the executive 
facilities, application tasks and hardware—allowing the 
fastest turnaround possible. 

To see how the RMX/86 operating system works, 
consider a typical example. Say an OEM develops a 
factory heating and air-conditioning control system 
with a single-board computer, analog I/O, special con- 
trol devices and operator terminal. He uses the nucleus, 
and terminal handler modules, plus user tasks stored in 
EPROM. 

But suppose the OEM’s customer wants to enhance 
the system with, say, disk storage. He simply adds a 
disk controller board and I/O system software. The 
original programs could also be made disk-resident. If 
the original application had been based on a conven- 
tional executive, extensive redevelopment would have 
been necessary. 

If, on the other hand, the application had used the full 
I/O system from the start, initial sales would have suf- 
fered because the OEM’s system would have been more 
costly. And if the software is not extendible, future sales 
are lost. | 

The historic problem with conventional ‘‘general- 
purpose”’ operating systems is that they usually depend 
on hardware that the application would not otherwise 
need—for example, large disk systems while a typical 
OEM system uses no mass storage at all. Modular 
operating systems are designed to accommodate a diver- 
sity of applications without undue hardware imposed 
on them. 

For an even closer fit with customers applications, 
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the RMX/86 modules closely parallel hardware 
modularity. 

Corresponding to the hardware, the RMX/86 nucleus 
manages CPU, memory and I/O sources. When linked 
to optional modules it can support standard iSBC 
devices like conscles and disk controllers. Similarly, 
users may add device driver software modules for their 
custom peripherals. All software can reside in EPROM / 
ROM if mass storage is not available. 

The RMX/ 86 operating system is designed for config- 
uration, to user specification, on an Intellec develop- 
ment system. The same system supports application 
software development as well as linking and locating 
both high-level and assembly language. 


What does a nucleus do? 


A real-time multitasking nucleus gives a program the 
means to monitor and control external events. Tasks 
running concurrently, using the services of the execu- 
tive are signaled with interrupts and the executive 
schedules resources for the tasks on the basis of priority. 
For example, a task trying to bring an oven’s tem- 
perature under control should have a much higher pri- 
ority than a report generating task. The nucleus’ sched- 
uler decides whether a running task should be inter- 
rupted to process data from an interrupting device. 

The RMX/86 nucleus makes event-driven priority 
scheduling possible by monitoring system states, deter- 
mining task requirements, allocating the resources and 
gathering the resources for reallocation after use has 
completed. Resources include CPU time, memory and 
I/O. | _ 

As in most priority based systems, the highest-pri- 
ority task that’s ready to run uses the CPU; others are 
put on a ready list. After servicing an interrupt, the 
nucleus returns the CPU to the highest-priority ready 
task. 


Managing memory space 


A memory manager, built into the nucleus, handles 
the 8086's megabyte addressing range, insuring that 
memory is used efficiently. The memory manager or- 
ganizes memory into a tree-structured hierarchy of 
pools according to each job's requirements, and pro- 
vides for allocation and deallocation of memory from 
these pools. When the nucleus or application tasks re- 
quire memory, the memory manager allocates it on the 
basis of segments that are multiples of 16-bytes (to 
65,536 bytes) corresponding to the 8086's segmented 
memory architecture. 

The RMX/86 nucleus provides three sets of facilities 
for tasks to communicate with one another. Each of the 
three is optimized for either data transfer, synchroniza- 
tion or mutual exclusion. | 

Mailboxes are provided to allow tasks to send data, in 
the form of segments, to one another. Since each seg- 
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ment is referenced by a description; of course, only 
pointers are moved rather than massive blocks of data. 

-Semaphores. offer low overhead mechanisms for syn- 
chronization operations. For example, one task can 
simply set a semaphore to tell another task that an 
event has happened (‘‘Analog data received’’). 

The third communication facility offers a unique 
mutual exclusion facility. Regions are defined as a body 
of code which manipulates a shared resource. The 
RMX/86 nucleus insures that while one task is manip- 
ulating the resource others don’t inadvertantly affect it. 

. All intertask communication functions are accessible 
with simple calls to the nucleus. For example, to access 
a mailbox the task simply names the mailbox desired. 
The programmer has no need to know the internal 
structure of the mailbox, since all functions are access- 
ible through easily programmed interfaces. 


Fault tolerance 


Another RMX/86 feature, exceptional-condition 
handling makes error handling simple rather than 
elusive. Programs can be designed to manage error con- 
ditions and take the appropriate corrective action. 

First, there’s an option to specify to the nucleus 
whether or not there should be any error handling for a 
particular task. A programmer can use a default handler 
to abort a task or he may program a specific course of 
action—for example, load a fresh copy of the program 
and try again. 

‘The. exception- -condition facilities also detect pro- 
gramming errors such as a wrong call to the nucleus and 
system problems, like insufficient memory. All-in-all 
the OEM will find that fault tolerance is no longer just a 
buzzword. 


Beyond the microprocessor 


Most microcomputers are used with a range of pe- 
ripheral devices, from serial lines to mass storage. 

The RMX/86 I/O system provides the user with a 
very general file concept; that of files as a data sink or 
source. The characteristics of specific storage medium 
dictate the access techniques for a given file. For exam- 
ple, a disk file may be accessed either in sequential or 
random fashion, while a file accessed over a serial link 
(USART) must be processed serially. 

_ Using the data sink/source concept, the user can de- 
velop application programs without worrying about the 
_ physical characteristics of the device. 

Such device independence simplifies application pro- 
gramming and allows programs to be used with a vari- 
ety of devices. 

The RMX/86 I/O ye supports three types of 
logical files: 

Physical files represent the lowest interface level 
which retains its device-independent characteristics. 
Physical files provide a simple, consistent interface to 
all device drivers. OPEN, CLOSE, READ, WRITE, 
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SEEK, and special instructions peur: all cesuey l/ o 
operations. — : 

Stream files. ee a ae data -transmission 
path between tasks. One task may write data to the 
stream file while another reads it. The I/O system per- 
forms the required synchronization and buffering. 


Stream files offer the user a simple mechanism for pass- 
ing data between tasks—one that remains consistent 


with other file options, thus allowing the user to 


simulate an external device while waiting for hardware 


to be built. 

Named files are used for the conventional data storage 
on mass- storage devices like floppy or hard disks for 
later access. However the RMX/86 I/O system goes 
one step further by setting up a hierarchical directory of 
files. This feature allows the user to organize his files to 
be consistent with his application. ~ 

- The named-file system has another advantage: It per- 
mits file-access checking,.so a user can decide which of 
his files he wants to protect and which to share with 


other users. 


Each of the file options can be conneaiea indepen- 
dently; so that the user mney select only the features he 
needs—nothing more. 

Furthermore, the RMX / 86 1/ O. system is cdeea to 
allow the user to easily add his own device drivers to the 
system as the need arises. 

The RMX/86 operating system was designed to offer 
the user a wide spectrum of convenient human inter- 
face functions. For example, the user of mass-storage 
systems is provided display directory and copy file 
utilities. Additionally, the OEM who needs his own 
interactive capability can either use the standard 
RMX /86 facilities or easily extend the system’s human 
interface routines to meet his specific application 
requirements. 


Summary 


The software crisis can be overcome only by in- 
troducing a broad base of system software functionality 
into the market, allowing OEMs to concentrate on their 
area of expertise. | 

Intel’s RMX /86 operating system takes a major stride 
forward in providing extendible, proven tools for OEMs 
to use in creating custom operating systems for their 
application. 

The RMX/86 operating system thus provides the 
OEM with a powerful new system building block, en- 
hancing the productivity of system generation. New 
dynamic tools like the RMX/86 operating system allow 


users to deliver their product into the marketplace 


much earlier, thereby capturing an important com- 
petitive advantage. 7 
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Modular multitasking executive 
cuts cost of 16-bit-OS design 


modular, real-time multitasking operating sys- 

.tem for single-board computers allows custom 
operating systems to be assembled largely from off- 
the-shelf software components. Such systems, when 
needed in OEM single-board uC applications, pose 
problems—rarely can an OEM afford man-years of 
effort to develop the intimate familiarity with the 
hardware that’s needed to design executive software. 


But with Intel’s RMX/86 system for iSBC 86 single- 


board computers, he won’t have to. 
In addition, this second-generation, 16-bit system 
added error-handling, flexible command-line decode, 


and other advanced OS capabilities to previous options © 


available on the older RMX/80. 

All real-time multitasking systems require ex- 
ecutive software not only to manage the resources 
shared by the task programs (CPU time, memory and 
I/O), but also respond to interrupts and then allocate 
the resources according to established priorities. Nor- 
mally, these functions are intermingled in an OS with 
higher-level system functions that often prove super- 
fluous in single-board computer applications. 

The RMX/86.OS package combines all those re- 
quired executive functions in a single module, called 
the nucleus. Other modules in the package tailor the 
executive system to its application by adding higher- 
level OS functions such as disk-file systems. The task 


programs and optional modules connect to the nucleus. 


with simple software interfaces. ta can also add 
their own extensions. 


Since the nucleus is essentially open-ended, it can a 


serve as the software foundation for expanding both 
the operating system and the variety of task pro- 
grams. Although most single-board computer applica- 


tions are dedicated, many do require higher-level — 


capabilities. 


The OEM way 


— The modular approach to system software fits in 
with the way most OEMs (and high-volume end users) 
apply single-board computers. They generally start 
with a minimum amount of hardware (often, just a 


Joseph Harakal, Software Product Manager, Intel Corp., 
5200 Elam Young Pkwy., Hillsboro, OR 97123. 
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In a real-time multitasking system, task modules (A 
through E) can often perform their functions only after 


hardware-generated interrupts are serviced (highlighted). 


The executive in such a system provides intertask 


communications and synchronization. 


RMX/80 vs RMX/86 features 
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single board) to begin an application at low cost. Then, 
when users are satisfied with the original functions 
and are willing to buy more, the OEM adds the 
executive options, tasks and hardware—with as fast 
a turnaround as possible. 

The problem with conventional “general-purpose” 
software systems is that they usually depend on 


hardware that the application may not need—for’ 


example, standard peripherals whereas a typical OEM 
system uses special peripherals. Modular OSs are 
designed to accommodate both. 

What’s more, a conventional system can make it 
difficult and/or awkward to use new peripherals or new 


technology, such as magnetic-bubble memory—most — 


command-line decoders, for instance, are not ac- 
cessible to the user. So, a user may discover that there 
is no straightforward way of adding new facilities. 


Call it foundation software 


For an even closer fit, with single-board computer 
applications, the RMX/86 modules closely parallel 
hardware modularity: Each computer board contains 
program and data memory, serial and parallel I/O, 
and other generally required functions i in addition to 


the CPU. Each user’s system is expandable with © 


optional modules. Frequently used devices like disk 
controllers and analog I/O are available. In addition, 
the user can connect custom devices to his system via 
the Multibus architecture. 

Corresponding to the hardware, systems stipe 
manages CPU, memory and I/O resources. Linked to 
optional modules,. it can support standard iSBC de- 
vices like consoles and disk controllers. Similarly, 
users may add device-driver software modules for 
their custom peripherals. All software can reside in 
EPROM/ROM if mass storage is not available; other- 
wise, most of the system can be disk-resident. The 
disk-file module is suitable for such applications as 
data logging. 

The RMX/86 is designed for configuration on an 


Intellec development system according to user re- 
quirements. The same system supports task-module © 


development as well as linking and locating in both 
high-level and assembly languages. It also provides 
libraries of frequently used program functions to 


minimize the amount of code the syetem neelanes : 


must write and debug. 


To see how the RMX/86 works, consider a typical 


example. Say an OEM develops a factory heating and 
air-conditioning control system having a single-board 
computer, analog V/O, special control devices and an 


operator terminal. He uses the nucleus, analog-han- . : 
dler and terminal-handler modules, plus user. tasks _ 


stored in EPROM. 


But suppose the OEM’s customer wants to enhance 
the system with, say, disk storage. He simply adds: 
a disk controller board and uses I/O system software. 
The original programs could also be made disk-resi- 


dent. If. the original application had. been. based on a 
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3. A hierarchical file system eliminates the need for . 
scanning all the files on a disk. If Smith is working on 
Project A, he only has to choose between the files related 
to his project. 
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conventional executive, extensive redevelopment 
would have been necessary. 

If, on the other hand, the application had used the 
full I/O system from the start, initial sales would have 
suffered because the OEM’s system would have been 
more costly. And if the software is not extensible, 
future sales opportunities are lost. 

A real-time multitasking executive gives a program 
the means to monitor and control external events. 
Tasks run concurrently, using communications and 
synchronization services of the executive (Fig. 1). 
Events are signaled with interrupts, and the executive 
schedules resources on the basis of priority—for 
example, a task trying to bring a factory under control 
should have a very high priority. The executive decides 
whether a running task should be interrupted to 
process data from an interrupting device. 

The RMX/86 nucleus makes such event-driven 
priority scheduling happen through resource man- 
agement. It monitors system states, determines task 
requirements, allocates resources and gathers them 
for reallocation. Resources include CPU time, memory 
and I/O. 

As in other systems, the highest-priority task that’s 
ready to run uses the CPU; others are put on a read 
list. Finishing the high interrupt, the nucleus returns 
the CPU to the highest-priority ready task. 


Managing inner space 


A free-space manager, built into the nucleus, han- 
dles the 8086’s megabyte addressing range, making 
sure that memory is used efficiently. The manager 
organizes memory into a tree-structured hierarchy of 
pools according to job requirements, and returns 
memory to pools. When the nucleus requires memory 
for a job, mailboxes or other functions, the manager 


_ provides it. Or, when a task requests memory—for 
example, to input data—the manager allocates it. This 


is done in segments that are multiples of 16 bytes, 
corresponding to the 8086’s segmented memory. 

Tasks send data to each other through mailboxes 
which contain messages located in RAM. As in other 
systems, separate mailboxes are used for receiving 
and for responding. | 

In the RMX/86, however, mailboxes provide several 
options, including synchronization, mutual exclusion 
(which prevents one task from destroying another 
task’s data) and communications—for example, with 
the outside world—through modules such as the 
terminal handler. 

The RMX/86 nucleus also provides other means for 
communications. One example is semaphores—low- 
overhead mechanisms for synchronization operations, 
resource allocation and mutual exclusion that require 
a simple flag. For example, one task can simply set 
a flag to tell another task that an event has happened 
(“Analog data received”). 

All these functions are accessible with simple calls 
to the nucleus. For example, just two calls are needed 
to use the free-space manager: CREATE-SEGMENT to 
request memory and DELETE-SEGMENT to relinquish 
memory. Likewise, to obtain an mailbox, the task 
simply names the mailbox desired. The programmer 
doesn’t need to know the internal structure of the. 
executive, since the functions are accessible through — 
easily programmed interfaces. | 


Errors, big and small 


Another RMX/86 feature, the exceptional-condition 
handling, makes error handling selective rather than 
all or nothing. Programs can be designed to manage ~ 


error conditions and take corrective action. 


Modular multitasking comes on 


Multitasking design is coming to the fore, especially 
for single-board-uC applications that usually require 
a lot more software than previous u.Cs—an advance 
from simple foreground-background programs to 
techniques based on event priorities. 

Although single-board uwCs started out in the 


mid-1970s at the low end of the OEM performance _ 


range, they have now reached the top in performance 
and memory capacity. As more and more OEMs and 
users take advantage of that increased capability, the 
size of applications programs grows—and grows. 

In the same period, the costs for developing software, 
salaries and overhead have almost doubled. Moreover, 
skilled programmers have become one of the 
industry’s most limited resources. No wonder that 
software costs comprise up to 80% of system develop- 
ment costs today, and that the emphasis has shifted 
from in-house software design to buying off-the-shelf 
programs. 

Because multitasking designs have to be highly 
modular, time-saving tools such as high-level lan- 
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guages, program libraries and off-the-shelf software 
can be used freely to help keep development, main- 
tenance and expansion costs under control. Code 
written in high-level languages is a bargain today, 
compared to code written in assembly language: 
around $2.50 a byte vs $10 for assembly language. 
High-level code is not as compact, but it’s far more 
cost-effective for the 80% of the tasks that run only - 
about 20% of the time in typical applications. 

Today, there’s a growing choice of languages. Struc- 
tured languages like PL/M and Pascal fit well into 
the “top-down” modular design technique used to 
divide an application into tasks. Others, like Fortran 
for mathematical applications and Basic for easy end- 
user programming, are also available. 

In general, a real-time multitasking executive offers 
a reasonable choice for the user who has a lot of 
software to write, must meet special requirements, - 
and has no time to develop a custom operating system. 
The RMX/86 system, with its modular age fills 
the bill to save development ¢ cost. 
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First, there’s an option to specify to the nucleus 
whether or not there should be any error handling 
for a particular task. A programmer can write his own 
handler either to abort a task or to program a specific 
course of action—for example, report exceptional 
conditions and continue with next instruction; load 
copy of module and try again; start alarm program. 

The exceptional-conditions support also detects pro- 
gramming errors such as a wrong call to the nucleus 
and system problems like insufficient memory. Natu- 
rally, the RMX/86 provides all normal OS functions. 
System options include a terminal handler for CRT 
and TTY consoles device drivers for Intel’s floppy and 
hard-disk controllers and an integrated I/O system. 
A subsystem of the I/O system supports tree-struc- 
tured directories hierarchical named files (Fig. 2). 


I/O features are vital 


Most single-board computers are used with special 
peripheral devices, and many with other kinds of files 
and media. So, the I/O system is designed to make 
it easier to add special files, new peripherals and 
custom device drivers—the user need never feel locked 
in. 

The RMX/86 I/O system provides the user with a 
very general file concept—as a data sink or source. 


TASKB1S 


The characteristics of a specific storage medium 
dictate the access techniques for a given file. For 
example, a disk file may be accessed either in sequen- 
tial or random fashion, while a file accessed over a 
serial link (USART) must be processed serially. 

Using the data sink/source concept, the user can 
develop application programs without worrying about 
the physical device where the data will be stored. Such 
device independence simplifies application program- 
ming, and existing programs can be used with many 
devices. 

The RMX/86 I/O system supports three types of 
files. 

Physical files represent the lowest interface level to 
retain device-independent characteristics. They pro- 
vide a simple, consistent interface to all device drivers. 
OPEN, CLOSE, READ, WRITE, SEEK and special instruc- 
tions perform all desired I/O operations. 

Stream files provide a temporary data-transmission | 
path between tasks. One task may write data to the 
stream file while another reads them. The I/O system 
performs the required synchronization and buffering. 
Stream files offer the user a simple mechanism for 
passing data between tasks—one that remains consis- 
tent with other file options. The user can simulate an 
external device while waiting for hardware to be built. 

Named files are used for the conventional data 
storage on mass-storage devices like floppy or hard 


FRUCKDURE PUBLIC; 


Call rgendsinitstask; 


CALL INIT; 
do forever; 


msagstoken=rgqreceivesmessage(malilboxsx, 
OFFFFH,€respsex,@exsval); 

call rgssend$message(rgsnormalsthsout, 
msastoken,outsresp, @exsval)3 | 


msgstoken= 


rqsreceivesmessage(cutsresr 


,OFPFRFFH,¢respsex,¢exsval); 
call ragdeletesseqment (msqgtoken, GEX$V 


al); 


end; 
ena; 


4. RMX/86 can easily be expanded with user-coded tasks. 
The one shown here initializes a user program by calling 
the procedure init and helps display messages. 
RQRECEIVE$MESSAGE is a system primitive that examines the 
mailbox to be serviced and places the token for the first 
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message there (MSG$TOKEN). Another system primitive, 
RQ$SENDMESSAGE, puts the token for the message into the 
terminal handler’s output mailbox. The primitive 
RQ$DELETE$SEGMENT Clears the used memory and returns 
it to the free-memory manager. 
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disks for later access by another system. However, 
the RMX/86 goes one step farther by setting up a 
hierarchical directory of files. This feature lets the 
user organize his files to be consistent with his 
application (Fig. 3). 3 

The named-file system has another advantage: It 


permits file-access checking, so a user can decide | 


which of his files he wants to protect and which to 
share with other users. 

Each of the file options can be configured independ- 
ently; the user may select the features he needs— 


neither more nor less. Furthermore, the user can add - }- 


his own device drivers to the I/O system. 


The RMX/86 is. designed. to offer the user a wide ; | 


spectrum of convenient functions (Fig 4). For example, 


the user of mass-storage systems has a display direc- 


tory and copy files available. Or, the OEM who needs 
his own interactive capability can easily extend the 
system’s human.interface routines to meet his require- 
ments. 

As uP applications expand, so does the need for 
loaders that allow parts of the applications software 
to reside on disks. The RMX/86 package provides a 
resident system loader that permits loading for either 
absolute or relocatable format. as 


How useful? is Circle No. 
Immediate design’ applicatio tee pe BML 
Within the. next year . 542 
Not applicable ee oy, SAB 
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A Small-Scale Operating System Foundation for 
Microprocesor Applications 


KEVIN C. KAHN 


Abstract—Sound engineering methodology, which has long been val- 
ued in hardware design, has been slower to develop in software design. 
This paper uses a case study of a small real-time system to discuss soft- 
ware design philosophies, with particuar emphasis on the abstract ma- 
chine view of systems. It demonstrates how the currently popular soft- 
ware design axioms of generality and modularity can be used to produce 
a software system that meets severe space constraints while remaining 
relatively portable across a family of microcomputers. These sorts of 
constraints have often been used to justify ad hoc design approaches in 
the past. The results of the project suggest that the use of such tech- 
niques actually make the meeting of many constraints easier than would 
a less organized approach. In addition, the reliability and maintainability 
of the resultant product is likely to be better. 


I. INTRODUCTION 


PROCESSOR, as defined only by its hardware, is typi- 
A cally not an adequate base upon which to build applica- 

tions software. Broad classes of applications can be ex- 
amined and found to share more than the hardware defined 
instruction set. To avoid the reengineering of this common func- 
tionality, we would prefer to build such common parts once and 
thereafter treat this base software as though it were part of the 
machine. For example, a software system sometimes called an 
operating system, an executive, a nucleus, a kernel, or some 
similar term, is often supplied with a hardware product and can 
be viewed in exactly this way. In this paper, we examine a small- 
scale system to demonstrate this approach to bridging the gap 
between the hardware and the application. That is, we will view 
the software as a direct extension of the hardware—a view which 
may indicate future directions in microprocessor integration of 
function. 

This paper is meant as both a case study of a particular system 
design and as a suggestion of the proper approach to such design 
situations in general. We will first discuss the abstract machine 
view of computer systems and attempt to demonstrate that this is 
a useful philosophical approach for building systems. We will 
then apply this approach to the discussion of a system to coor- 
dinate programs performing real-time control functions— RMX- 
80™ [18]. The emphasis of the paper will be on techniques and 
methodology rather than on the particular functionality of RMX. 
Special attention will be given to such issues as the use of 
modularity to enhance the adaptability of the system and the use 
of design generality to achieve global rather than local optimiza- 
tions. 


II. THE CONCEPT OF ABSTRACT MACHINE 


What is a computing ‘‘machine’’ or processing unit? We gen- 
erally identify a processing unit as a particular collection of hard- 
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ware components that implement the instruction set of the 
machine. This very physical definition of a computer dates from 


‘mechanical processors. Even with modern computers, before 


large-scale integration, it was easy to physically point at the proc- 
essing elements as distinct from memories, peripherals, and pro- 
grams. Continued integration of function has at least made this 
physical distinction more difficult with single chips subsuming 
processing, memory, and peripheral interface functions. Micro- 
programming (i.e., replacing hardwired instruction logic with a 
more elementary programmed processor) as an implementation 
strategy has logically blurred this distinction as well. That is, 
when the basic visible instruction set of a processor is itself imple- 
mented in terms of more primitive instructions it is more difficult 
to identify ‘‘the machine.”’ It is clear that this narrow physical 
definition of a processor is not adequate for current technology 
levels and is likely to become even less viable as the technology 
continues to develop. | 

Actually we have been using alternative definitions of a proces- 
sor for some time. All of the theoretical work in finite state 
machines, for example, deals with conceptual processors. Like- 
wise applications programmers seldom really regard the machine 
they program as much more than collection of instructions found 
in a reference manual—the physical implementation of the 
machine is of little concern to them. Indeed, they may never come 
physically near the hardware if they deal with a typical time- 
sharing system—rather, the terminal is the only physical manifes- 
tation of the computer such users may see. 

More to point, perhaps, are the numerous interpreters that 
have been written for languages such as Basic. Each such inter- 
preter actually produces a conceptual machine with one instruc- 
tion set targetted to a specific application. With standard com- 
piled languages such as Fortran, Algol, or Pascal, a higher level 
source statement is translated into the instruction set of the 
physical hardware. In contrast, interpreted language systems 
translate the source into the instruction set of some conceptual 
machine that is better suited to the running of programs written in 
the language. For example, the hardware may not provide 
floating-point instructions or define a floating-point data repre- 
sentation. In such a case it may be easier to define a machine that 
recognizes a particular floating-point data format with an instruc- 
tion set that includes floating operations. These interpreters are 
high-level machines that have usually been implemented in soft- 
ware. Likewise, it should be readily apparent that, just as these in- 
terpreters provide high-level machines to their associated trans- 
lators, any programming language, compiled or interpreted, pro- 
vides one to its users. 

Interpreters of this sort typically may examine and decode a 
stream of instruction values in a manner analogous to the hard- 
ware. Alternately, the new instructions may all be executed as 
subroutine calls using the appropriate hardware instruction. That 
is, the entire bit pattern for CALL X (where X is the address of a 
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Fig. 1. Typical collection of abstract machines. 


routine that implements a part of the new instruction set) can be 
regarded as a new operation code rather than as the hardware 
operation CALL. In either case the programmer using these exten- 
sions’ can view the harware-software combination as though it 
were a new machine with a more useful instruction set. Micropro- 
grammed machines such as the IBM 5100 or Burrough’s 1700 
have simply optimized the performance of such interpreters or 
subroutine packages by committing them to a faster storage 
medium. 

Viewed in this light we can identify any collection of hardware 
and software that provide some well defined set of functions as 

defining an abstract machine [10],[12]. This machine has an in- 
- struction’ set that consists of the functions provided by the hard- 
ware-software combination. For a particular application it may 
be possible to view multiple such abstract machines by taking 
various pieces of the whole. For example, the physical machine 
provided by a set of components is just one abstract machine. It is 


of particular interest since it is the greatest common abstract: 


machine that can be identified as being used by any application 
running on that computer system. A Basic interpreter running on 
this machine might then constitute a second virtual machine. A 
Basic program running on this interpreter that accepted high level 
commands and performed according to them might be a third 
level machine’ usable by people with no knowledge of either the 
hardware or Basic. Whenever we can identify functions of suffi- 
cient commonality among a number of applications, it may be 


worth viewing the software which provides these functions as ex- 


tensions of the base hardware machine which define somé aug- 
mented or even different machines. Users programming such an 


application can then view this abstract machine, rather than the - 


base machine as the vehicle that they are programming, and in 
doing so avoid reengineering the functions that it provides. Fig. 1 


illustrates an example of such machines. It is important to remem- 
ber that at any time, many abstract machines may be thought of 


as existing on the same pase hardware. 


III. OPERATING SYSTEMS AS ABSTRACT MACHINES 

The terms operating system or ‘executive have been used to 
describe software systems of widely different functionality. These 
machines generally provide for the management of some machine 
resources such as input, output, memory space, memory access, 
or processor execution time. We might then attempt to define an 
operating system as some collection of software modules which 
defines an abstract machine that includes resource management 
functions as well as the hardware supplied computational func- 
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tions [2],[6],[8],[11]. With such a broad definition, however, 


. large-scale multi-user’ time- sharing. systems and small. single user 


microprocessor ' ‘development systems both -may. claim to have 
operating systems. Clearly, the range of software systems covered 


_, by.this definition is large,’ encompassing products which differ by 
orders of riagnitude i in complexity. Rather than become involved 


in trying to resolve this disparity, we will qualify our use of the 
That is, we 
will describe a software system which provides a minimal base for 
the construction of real-time applications. We will avoid the 
somewhat irrelevant question of whether the system COmpRses a 
complete ‘“operating system. Q ; ; 

The important item to realize from the above discussion’ is that 
any operating system functionally enlarges the processor seen by 
the programmer. The functions that it provides become as mucha 
part of the machine’s functionality as jump instructions. Indeed, . 
it is functionally unimportant to the user desiring to read from a 
file whether it requires a single hardware instruction or a large 
software routine. to accomplish it. In terms of the abstract 
machine discussion above, we will examine a software package. 
which defines an abstract machine that includes functions re- 
quired to coordinate programs performing real-time control ap- 
plications [1],[9],[12]. 

The key overall requirement of the operating sytem foundation 
that we discuss in this paper will be that it supply a minimal cover- 
ing set of functions to permit coordination of asynchronous 
tasks. To.determine this set we will need to further examine the 
needs of its users and environment of its use. In describing this 
foundation, we are. defining an abstract machine that must be 
programmed to be of use; that is, like the instruction set of the 
base. machine the foundation by itself performs no work but 
rather provides an environment within which useful tasks.can be 
run. — = 

We Head note, here, some of ihe ‘inmltations of ‘the uetzi 
which differentiate it from large-scale operating systems. First, it 
is not primarily intended for a multi-user environment, particu- 
larly because.the underlying hardware does not provide the neces- . 


"sary support to protect users from one another. Also, it will often 


be used to control functions of specialized devices and therefore is 

“‘close’’ to the I/O devices. That is, it does not supply the sort of 
high level I/O control system which is often present in larger sys- 
tems for controlling more conventional I/O devices. Finally, it. 
does not assume a backing store from which program overlays. 
can be loaded (but it can easily support such an extension). 


IV. DESIGN CONSIDERATIONS _ 
A. Use Environment 


The foundation system we will describe is RMX-80 5) which | 
was designed’ to be used with members of Intel’s Single Board 
Computer (SBC) family of products. This. family includes a wide 
range of bus compatible processor, memory, and peripheral 
boards. Of most interest to this discussion are the processor 
boards which are based on the Intel 8080 or 8085 microprocessors 
and include varying amounts of on-board ROM and RAM mem- 
ory and I/O interfaces. In addition, the boards vary in the sophis- 
tication of their interrupt structures and timing facilities. In terms 
of abstract machines we might characterize these computers as 
essentially the same machine at the processor level but different 
machines at the computer system level. It was desired that the 
abstract machines defined by adding RMX to the underlying com- 
puters be as much the same as possible. 

During the design of RMX, we expected that its users would 
span the entire broad range of applications across which the SBC 
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hardware was being put to use. This implied that it might see uses 
ranging from minimal single board systems that functioned. as 
single device controllers to complex multiboard applications im- 
plementing involved real-time process or industrial control func- 
tions. In particular we expected that many user-built I/O boards 
and peripherals would be used with the system. It was important 
for us to allow full use of these unknown devices with RMX while 
still providing as much assistance as eee in the building of the 
controlling software systems. 

As is the case with most processors, the concrete (i.e., physical) 
machines represented by the SBC family do not fhientselves in- 
clude any facilities to permit multiple asynchronous functions to 
be programmed, to provide for the coordination of such func- 
tions, or to provide time information needed for real-time ap- 
plications. Typically, users of these products have directly pro- 
grammed these functions in an ad hoc manner within their ap- 
plications. An examination of the sorts of functions necessary to 
such applications reveals that at the very least this reengineering is 
a waste of resources. Worse is the high Doane of error in pro- 
gramming such critical functions. 

The SBC hardware products were designed to eliminate the 
complexities of board engineering, particularly for those users 
without the necessary expertise to handle the task, by functionally 


integrating individual components into complete boards. The 


programming of functions to coordinate parallel software activi- 
ties is, likewise, an area which should be carefully engineered in 
order to avoid subtle errors. The development of RMX was there- 
fore viewed as a process of functional integration analogous to 
the integration of LSI components into boards. That is, just as a 
well designed board relieves the user of component level hardware 
engineering, RMX relieves the users of low-level software engi- 
neering. . 


B. System Requirements 


The hardware environments and anticipated uses of RMX de- 
fined a stringent set of requirements for it. Foremost among these 
were its memory constraints; indeed, for the anticipated uses, 
memory size considerations dominated execution speed ones over 
a considerable range. Since we expected applications that would 
reside entirely on a single board with 4K bytes of PROM, the 
maximum size of the RMX foundation code was set at half of this 
or 2K bytes. Further, unlike larger minicomputer systems, many, 
if not most, applications of the SBC boards would not have avail- 
able any mass storage or other program loading device. It was 
thus important that RMX be designed to be ROM (or PROM) 
resident and capable of automatically initializing the system when 
powered on. 

We also anticipated that the expertise of many RMX users 
would be in areas other than programming systems. We therefore 
felt that the RMX machine needed to provide a fairly simple set of 
concepts, avoiding where possible those constructs most likely to 
cause errors. For example, we felt that a very frequent source of 
programming difficulty lay in dealing with interrupts. Many 
latent errors in programming systems stem from the occurrence of 
an interrupt at an unexpected time. We therefore decided to at- 
tempt to minimize the need for users to deal with hardware inter- 


rupts of with the interrupt-like occurrences found in many mini-— 


computer operating systems. At the same time we had to accom- 


modate the needs of the sophisticated user who still desired to 
take advantage of RMX but hada specific need to directly control | 


the hardware via the interrupt facility. 


Finally, to define the general functionality of RMX we exam- 


ined its anticipated applications. Real-time applications com- 
monly need to perform a number of tasks of differing importance 
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logically in parallel, with preference always being given to execut- 
ing the most critical ones first. While these tasks may be relatively 
independent, they may need to periodically synchronize them- 
selves with one or another distinct task or with the outside world. 
For the latter, interrupts are the usual hardware supplied mecha- 
nism. Some tasks may also need to communicate data with one 
another. For example, a task servicing a sensing device may take 
readings from the device which need to be communicated to two 
tasks: one task .which reacts to the reading by controlling some 
other device, and another task which logs or tabulates the read- 
ings. Ranked in order of importance these might be control, sens- 
ing, and logging. Finally, the tasks must have the ability to con- 
trol themselves relative to real-time, either by delaying their exe- 
cution for certain periods or by guaranteeing that they are not in- 
definitely delayed by, for example, a faulty device. 

Requirements on the system design were also generated by .con- 
siderations internal to the design project. One of these was the 
need to provide a single RMX abstract machine on a variety of. 
underlying SBC boards. While separate versions of RMX for each 
board could have been designed with the same external appear- 
ance, this approach would have led to an unnecessary amount of 
internal engineering. Additionally, without careful initial design, 
the differences in the base hardware would have had visible ef- 
fects on the RMX: abstract machine for each of the boards. This 
requirement demanded that we partition the structure of RMX 
into two parts. One part would implement those aspects which 
were independent of the particular hardware. The second part | 
would: interface the first part to the underlying hardware of the 
specific boards [7]. 

We also wished to minimize the soriware: deveioinent boas by 
applying the best available software engineering techniques. His- 
torically, tight space constraints have often led to a very ad hoc. 
approach to software design in the belief that more generally 
designed external features or more modularly built internal 
designs would lead to inherently larger systems. As a result of this 
philosophy, each needed function is designed to be as small as. 
possible. Unfortunately, while each function may be locally opti- 
mized, it is possible that the overall design suffers from duplica- 
tion or overlap between such individual elements. Current work 
in programming methodology stresses modularity, generality, and 
structure (most often for their side effects in producing more 
maintainable, less error prone systems). . 

We felt that there was more to gain, both in development cost 
and space performance, by avoiding optimized specialization of 
function in favor of more general designs [17]. This reduced the 
number of separate functions that RMX had to supply. The re-. 
sulting external design therefore has a single mechanism that pro- 
vides task communication, synchronization, time references, and 
standard interrupt-like control. To do so..it incorporates the 
operating system design approaches favored in much of the mod-. 
ern computing literature. Likewise, the internal structures are 
highly modular and designed to be as uniform as possible so as to 
avoid replicating similar, but nonidentical internal management 
routines. 


; V. THE RMX MACHINE 
B. General Cancepis 


The abstract machine defined . RMX augments the: base 
microprocessor by introducing some additional computational 
concepts. We define a task to be an independently executable pro-- 
gram segment. That is, a task embodies the concept of a program 
in execution on the processor. RMX permits multiple tasks to be 
defined which can run in a parallel, or niultiprogrammied, 
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fashion. That is, RMX makes individual tasks running on one 


processor appear to be running on separate processors by manag- 
ing the dispatching of the processor to particular tasks. The reg- 
isters on the processor reflect the activity or state of the running 
task. Other tasks may be ready to execute but for some reason 
have | not been selected to run yet and so have their processor 
states saved elsewhere in the system. From the point of view of the 
program that is a task, execution proceeds as though it were the 
‘only one being run by the processor. Only the apparent speed of 
execution is affected by the multiprogramming. From the point of 
view of the system, every task is always in one of three states: run- 
ning, ready, or waiting. The task actually in execution is running. 
Any other task which could be running but for the fact that the 


system has selected some other task to actually use the processor, | 


is ready. Tasks which are delayed or stopped for some reason are 
waiting, as will be discussed below. 

Each task is assigned a priority which determines its relative im- 
portance within the system. Whenever a decision must be made as 
to which task of those that are ready should be run next, the one 
with the highest priority is given preference. Furthermore, in the 


; ‘spirit of unifying mechanisms, the same priority scheme replaces a - 


separate mechanism for disabling interrupts. Interrupts from ex- 
ternal devices are logically given software priorities. If the ap- 
plications system designer deems a particular task as of more im- 


portance than responding to certain interrupts, he can specify this | 


by simply setting the RMX priority of that task to be higher than 
the RMX priority associated with those given hardware inter- 
rupts. It is thus possible to maintain a high degree of control over 
the responsiveness required for various functions. 

_ As mentioned above, tasks may desire to communicate infor- 
mation to one another. To this end the RMX machine defines a 


_message to be some arbitrary data to be sent between tasks. To’ 


mediate the communication of messages it defines an exchange to 
be: the conceptual link between tasks. An exchange functions 
somewhat like a mailbox in that messages are deposited there by 
one task and collected by another. Its function is complicated by 
the fact that a task: may attempt to collect a message at an ex- 
change that is empty. In such a case the execution of that task 
must be delayed until a message arrives. Tasks that are so delayed 
are in the waiting state. We chose this indirect communication 
mechanism over one which directly addresses tasks because it per- 
mits’ greater flexibility in the arrangement of receiver and sender 
tasks. The anonymity of the receiving task implies that the sender 
need know only the interface specification for a function to be 
performed via a message to a particular exchange. The task or 


tasks which implement that function need not be known and > 


hence may be conviently changed if desired. 
| “The conventional mechanism used by programs to communi- 
cate. with external devices is the interrupt. Unfortunately, inter- 
rupts are by nature unexpected events and programming with 
them tends to be error prone. The essential characteristic of an in- 
terrupt is that'a parallel, asynchronous activity (the device) wishes 
to communicate with another activity (a program). Since this 
communication is essentially the same as that desired between 
separate software tasks it seems conceptually simpler to use the 
same message and exchange mechanism for it. The unification of 
all communications functions is analogous to the idea of stand- 
ardized I/O found in systems such as UNIX [17]. The RMX 
machine eliminates interrupts by translating them into messages 
which indicate that an interrupt has occurred. These messages are 
sent to specific exchanges. associated with particular interrupts. 
Tasks which “service interrupts” do so in RMX by attempting to 
receive a message at the appropriate exchange. Thus, prioritized 


nested interrupts are easily handled. An advantage of this unfied 
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treatment of internal and external communication is that hard- 
ware interrupts can be completely simulated via another software 
task. This facilitates debugging and permits easy modification of | 
a system by allowing rather arbitrary insertion of tasks into a net- | 
work of communicating tasks and devices. 

Note that with this scheme unexpected interrupts do not cause 
particular difficulty. For example, if the servicing task is still busy 
with some previous message, the interrupt message will be left at 
the exchange and will not affect the task until it is ready for an- 
other interrupt; i.e., until it waits at the exchange. In an applica- 
tion designed to properly handle the actual interrupt rate, the task : 
will service interrupts quickly enough to always be waiting when 
the next one occurs. In this case, response to an interrupt is im- 
mediate. Thus this mechanism provides no loss of facility relative 
to the usual interrupt scheme but it does make the proper con- 
trolling of such events simpler. Multiple occurrences of the same 
interrupt which indicate the processor has fallen behind in its ser- 
vicing are logged as such by a message which indicates that inter- 
rupts may have been lost. These interrupts do not, however, dis- 
rupt the running task or complicate programming. 

The last concept embodied in the RMX abstract machine is that 
of time. The RMX machine defines time in terms of system time 
units. It then permits tasks to delay themselves for given periods 
of time so that they can synchronize themselves with the outside’ 
world. It also permits tasks to guard against unduly long delays 
caused by attempting to collect a message at an empty exchange 
by limiting the length of time that they are willing to spend 
waiting for some message to arrive. 


B. Data Objects and Functions 


These concepts are realized in RMX by introducing some new 
data objects and instructions. Just as the base processor can deal 
directly with such data objects as 8 bit bytes or unsigned integers,. 
the RMX abstract machine can deal directly with the more com- 
plex data objects: task, message, and exchange. Each of these 
data objects consists of a series of bytes with a well defined struc- 
ture and may be operated upon only by certain instructions. This 
is completely analogous, for example, to a machine that permits 
direct operations on floating-point data objects which consist of 
four bytes with a particular internal structure to represent the 
fraction, exponent, and signs. In each case there are only certain 
instructions that can be used correctly with the object and the in- 
ternal structure of the object is not of particular interest to the 
programmer. | 7 

The new instructions provided by RMX are: SEND, WAIT, AC- 
CEPT, CREATE TASK, DELETE TASK, CREATE EXCHANGE, and 
DELETE EXCHANGE. The create instructions accept blocks of free 
memory and some creation information to format and initialize 
the blocks with the appropriate structure. Each corresponding 
delete instruction accepts one of the objects and logically removes 
it from the system. The remaining operations are of more direct 
interest to the operation of the RMX machine. 

The WAIT instruction has two operands: the address of an ex- 
change from which a message is to be collected and the maximum 
time (in system units) for which the task is to await the arrival of a 
message. The result of the operation is the address of the message 
which was received. A special message from the system indicates 
that the specified amount of time elapsed without the arrival of a 
normal message. From the programmer’s point of view this in- 
struction simply executes and returns the specified result. Actual 
execution of the instruction will involve the delaying of task exe- 
cution if no message is available, by queueing it in a first-come- - 
first-served manner at the exchange. Any such delay is not visible 
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to the programmer, however. This approach unifies the commun- 
ication and timing aspects of the design. It directly provides reli- 
ability in the face of lost events due to hardware or software fail- 
ure. Tasks can be guaranteed not to be indeterminately delayed 
due to such failures and can thus attempt recovery from them. It 
also permits tasks to use the same mechanism to delay themselves 
for given time intervals by walling at an exchange at which no 
message will ever arrive. 

The ACCEPT instruction is an alternate way to receive a mes- 
sage. It has a single operand specifying the exchange from which 
the message is to be received and immediately returns either the 
next message at the exchange or a flag indicating that no message 
was available. The task is never delayed to await a message in the 
ACCEPT operation. 

SEND also has two operands: the address of a message and the 
address of an exchange to which the message is to be sent. The in- 
struction queues the message in a first-come-first-served manner 
at the exchange if there is no task already waiting there. If a task is 
waiting at the exchange then the instruction binds the message to 
the task and makes the task eligible to execute on the processor. 
When the receiving task resumes actual execution the address of 
the message will be returned to it as the result of its WAIT instruc- 
tion. 


VI. THE RMX IMPLEMENTATION 
A. Methodology 


In this section and the next, we consider some (but certainly not 
all) details of the actual implementation of the system as illustra- 
tions of the design of such software products. We turn first to the 
methodology applied to the effort and then to some ae of 
the mechanisms. 

To provide the abstract machine just described and meet the 
other requirements for the system, RMX was implemented as a 
combination of ROM resident code and.some RAM resident 
tables. Just as a hardware designer uses LSI devices in preference 
to: more elementary TTL components, we chose to use the 
leverage of a high level programming language rather than 
elementary assembly code. The system was, therefore, designed 
using PLM [14], Intel’s high-level implementation language. The 
operations described above appear as procedure calls using the 
standard PLM calling sequence. The space constraints and a good 


level of internal maintainability were achieved by maximizing the 


modularity of the design. The broad independent functions of 
multiprogramming, communications and control were completely 
isolated from the board dependent timing and interrupt handling 
functions. As a result, movement of the system to a new member 
of the SBC family requires only the reimplementation of these 
board dependent functions. In addition, data structure of internal 
and user visible objects were generalized so that single algorithms 
could deal with any of them. Individual optimizations could have 
been made in the local design of many parts of the data structures 
to improve their space or time costs slightly. Such optimizations, 
however, would have cost considerably more. in code space and 
code complexity [3]. 

The module feature of PLM was used to simulate the abstract 
data type concept [4],[13] and enforce information hiding [15], 


[16]. That is, every data structure used by RMX is under the ex-. 


clusive control of a single module. The modules supply to each 
other restricted sets.of public procedures. and variables. It is only 


through these paths that agents outside a module may access the. 


data structures maintained by the module. The only assumptions 
that such outside agents may make about a module and its data 
structures. are those specified by the definition of the public paths. 
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Fig. 2. Major modules (boxes) and data structures (circles) of RMX. 


As a result, so long as these interface specifications are main- 
tained, any given data structure may be reorganized by redesign- 
ing its controlling module without affecting other parts of the sys- 
tem. This approach improves the understandability of the imple- 
mentation and facilitates the debugging and maintenance of the 
system. Fig. 2 illustrates the general structure of the RMX mpc 
mentation. 

Finally, the original version of RMX was csapieeis coded i in 
PLM using: the resident PLM compiler of the Intellec®. Micro- 
computer Development System. This version was functionally 
complete but slightly exceeded the space constraints, occupying 
about 2.5K bytes of program space. There were a couple of cases 
where the language structure of PLM did not permit the direct ex- 
pression of the best way to compile the code. For these modules, 
it was sufficient to hand optimize the code output by.the com- 
piler. The original structure of the PLM program was maintained. 
and the. majority of its generated code was used intact. The final 
RMX system occupies-less than 2K bytes of program space. This 
high level language approach coupled with selective manual opti- 
mization permitted far quicker and more error free development. 
than could have been achieved using assembly language. 

The approach to handling interrupts did introduce additional. 
software overhead. For a typical configuration of the hardware, 
the realistic minimum interrupt latency would be about 200 us. 
Using the message mechanism it is about 800 us. For the targetted 
process control applications, this is entirely acceptable... RMX 
does make provision, however, for direct handling of selective in- 
terrupts which require better response time without disturbing the 
use of the message mechanism for the others. For normal task 
communication, the performance is relatively better, For the typ- 
ical hardware configuration, the transmission of .a message takes 
about 800 us, which is comparable to the time that would be re- 
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quired for any synchronization primitive (e.g., P and V or en- 
queue and dequeue) on such hardware. 


B. Engineering for Hardware Dependencies 


The two functions which vary most significantly across the SBC 
product line are the timing and interrupt facilities. To accom- 
modate these variations, the implementation separates the logical 
and physical parts of these functions. 

The interrupt facilities are split between the module which im- 
plements the communications operations and a hardware inter- 
rupt handler module. The communications module provides a 
special ‘‘interrupt send’’ operation which performs the logical 
translation of the interrupt event into a message. This facility is 
independent of the interrupt structure of the processor board and 
remains the same in any version of RMX. The hardware depend- 
ent interrupt module deals directly with the hardware interrupt 
structure and invokes the send operation at the logical level. Only 
this module need be redesigned when generating an RMX version 
for a different SBC board. With this approach we take full advan- 
tage of the hardware vectored priority interrupt structure on high 

performance products and can simulate this desirable structure at 
- slightly higher software cost on low performance products. 

The same sorts of variations are faced in providing a source for 
the system time unit. Again, one module provides all of the 
logical time functions associated with providing time delays and 
time limits to the user system. This module is independent of the 
type, frequency, or location of the physical time source. A sep- 
arate module is responsible for clocking the logical level by invok- 
ing it once every system time unit. Once again, this permitsa con- 
sistent definition of time in RMX systems regardless of the sophis- 
tication of the available time source, and it limits the amount of 
reimplementation that:is needed to support new SBC products. 


C. Example Data Objects 


~ As an example of the complex data objects defined in the sys- 
tem we will consider the task and exchange objects illustrated in 
Fig. 3. The task object is 20 bytes long and embodies the execu- 
tion-state and status of a task. It consists of pointers used to link it 


onto various lists of: tasks in the system. These lists are used to 


queue a task at an exchange, link it to other ready tasks, or keep 
track of its maximum. delay when waiting. It also contains the 
stack pointer of non-running tasks which is sufficient to supply 
the remaining task register values when the task next executes. 
Finally, the object contains the task priority, some status infor- 


mation describing the state of the task, and a pointer to auxiliary’ 


information about 'the task. ° - 2 


The exchange object is 10 bytes long and implements the mail-: 


box concept described earlier, primarily by serving as the source 


of header information for lists of messages and tasks. Each of 
these singly linked lists is addressed with head and tail pointers 
located in the exchange object. All exchanges in the system are 


also linked together. . 
The exchange objects are operated: upon by the SEND, WAIT, 
and ACCEPT instructions of the RMX abstract machine. These in- 
structions generally alter the ‘‘value’’ or contents of these com- 
plex data objects. The task object is not the direct operand of any 
RMx instruction described above. Rather it is indirectly altered as 


a side effect of various instructions. Just asthe user of floating-' 


point objects on most machines needs to know the length and ex- 
istence of instances of the object, but not its internal structure, so 
the internal structure of these objects .is generally unimportant to 
the users. | | : a ot 
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Fig. 3. Example data objects in RMX. 


D. Global Versus Local Optimizations 


We have already discussed some aspects of global versus local 
optimizations at the overall design level in terms of avoidance of 
redundant features. A good example of this tradeoff in the imple- 
mentation is provided by the linked list data structures within 
RMX. Like many such systems there are a number of singly 
linked lists which must be maintained to reflect the status of the 
system. Local optimizations on the placement of links within data 
structures or in the form of the headers used for the lists would be. 
guaranteed to save a few bytes of data space across the various 
lists. Further, the list insertion, scanning, and deletion algorithms 
could be specially tailored to the individual list structures to save 
microseconds of execution time for some operations on some 
lists. Indeed, any one such tailored algorithm might well use less 
code space than a single more general one. : 

On the other hand, many of the list operations are in no sense 
time critical. Generalizing all the list structures to use a single 
form replaces multiple algorithms with one, thus saving code 
space. The particular form can be chosen to favor those opera- 
tions that are frequent, thus limiting the impact.of the generaliza- 
tion on the execution speed of the system. Perhaps most impor- 
tant, however, is that, by reducing the number of algorithms and 
structures used, we decrease the potential number of errors and 
improve the maintainability of the resultant product. Since there 
are, for example, at least six distinct singly linked structures in the 
system, we reduce overall code size and engineering cost by sup- 
porting only a single mechanism. We improve product reliability 


at the price of a small increase in fixed data space and a small exe- 


cution speed penalty of infrequent and nontime-critical opera- 
tions. z 

It is interesting to note as an aside that this is really an example 
of software engineering: that is, applying engineering discipline to 
software development. Such discipline is highly valued and under- 
stood in other engineering fields. Standardized mechanical or 
electrical: components are virtually always preferred to special 
designs; PLA’s often replace random logic. Unfortunately, an ap- 
preciation of the overall benefits of such: structure has. been slow 
to develop in software engineering. Too often, we have seen 
special purpose designs and overly complex structure used in pro- 
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grams supposedly to save space or improve speed. The true costs 
in development time and reliability of such approaches have often 
been underestimated; the true time savings attributed to them 
often overestimated. The high percentage of end product cost due 
to software is finally forcing a general awareness of these issues. 


VII. LSI AND ABSTRACT MACHINES 


It seems natural at this point to ask how the abstract machine 
view of systems in general and our experience with RMX might be 
affected by the continuing development of LSI technology. Once 
we view any complex software system as defining a collection of 
abstract machines, it becomes obvious that it is simply an engi- 
neering decision as to which machines should be committed to 
hardware. We are constrained in this choice by the densities of 
our solid-state technology, the performance we desire, the ap- 
plications that we are attacking, and perhaps most severely, by 
our understanding of software systems and of the machine struc- 
tures that they require. 

We might build an entire final application (e.g., a cash register) 
as a very-high-level single-chip machine. The specialization of 
such a design would, however, severely limit its application 
beyond the one for which it was specifically meant. On the other 
hand, we could build exclusively bit slice microprogrammable 
machines with utmost generality but which, due to their very low 
level of functional integration, would have no technological lever- 
age for attacking complex problems. Actually, both these ex- 
tremes have their well developed roles and will continue to be 
reasonable approaches for high-volume low-cost, and special- 
purpose tailored systems, respectively. It is in the middle ground 
—the area of the traditional computer—that directions are less 
clear. 

If the 8080 type processors are generally somewhat less power- 
ful than we actually need and as a result we always build operating 
systems of some level to support them, perhaps some of these 
functions can be integrated into the hardware. That is, if we can 
identify a broad range of systems which include essentially the 
same abstract machine implemented in software, then that 
abstract machine is a good candidate for hardware integration. 
The engineering difficulty is in understanding these software 
structures well enough to confidently and correctly commit them 
to hardware. 

Attempting to build all of some very large and complex operat- 
ing system onto one or two chips is, no doubt, out of the question 
with current technology. On the other hand, the final RMX sys- 
tem which we described resides in a small amount of ROM within 
the 65K address space of the 8080 processor. Once we view RMX 
as an abstract machine, the placement of the code which imple- 
ments its functionality becomes immaterial. In particular, we 
could build an augmented 8080 type processor directly by defining 
the additional instruction codes of RMX as hardware operations 
and moving the RMX implementation into microcode on the 
chip. The resultant component would indeed be an ‘‘RMX ma- 
chine’’ which dealt directly with the complex data objects and 
tables described above. It would have the advantage of not using 
any of the address space for operating system code. More impor- 
tantly, it would not waste bus cycles and memory access time 
fetching operating system instructions. Such a machine would 
have the same advantages over a conventional one that a machine 
with floating-point hardware has over one without it. 

Should we then try to build the RMX machine—ignoring for 
the moment whether our hardware technology is capable of it 
quite yet? Is the simple task model of RMX sufficiently general to 
be of use over a wide class of applications? Is the RMX machine 
the complete tool that we would like? Clearly, the answer is not a 
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wholehearted yes. For one example, RMX provides no isolation 
or protection of one task from another. Indeed, no solely soft- 
ware system can provide such protection at any reasonable cost. 
Such isolation would be desirable at the least because it would 
limit the damage that one task could do to another due to errors. 
The conclusion to be drawn, therefore, is not that this particular 
abstract machine should be built in hardware, but rather that 
some such machine would provide more of the facilities needed 
for building microprocessor applications than do current proces- 
sors. Further, the design principles discussed above are the ones 
that appear most likely to be fruitful in creating such a machine. 


VIII. CONCLUSIONS 


In this paper, we have attempted to use a case study of a partic- 
ular small operating system to illustrate both a philosophical ap- 
proach to viewing computer systems and some important aspects 
of software development methodology. Many of the subtle as- 
pects of desiging software to control quasi-parallel activities have 
not been discussed in detail, nor have we fully described the im- 
plementation. Nevertheless, we hope that this description suggests 
the practicality and necessity of disciplined approaches to soft- 
ware system design. Until software implementation reaches a level 
of engineering commensurate with that applied to other aspects of 
computer system design, our products will be very much bound 
by software costs. Only discipline and structure within our soft- 
ware efforts will ultimately permit microprocessor applications to 
reach their full potential. 
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Faster and smaller than its predecessor, the IRMX 88 real-time 
_ modular operating system eases the transition from 8-bit to 16-bit 
uCs, while supporting the 8087 arithmetic chip and other peripherals. 


Multitasking executive 
speeds 16-bit micros 


Even while it eases the transition from an 8-bit 
to a 16-bit world, a new operating system (OS) brings 
thoroughbred performance to the stable of modular 
systems software. The iRMX 88 multitasking ex- 
ecutive cuts both interrupt latency (the delay until 
a random event gets a response) and context- 
switching time (the interval during which the proces- 
sor changes from one task to another). Its nucleus 
is, therefore, faster—and smaller—than those of 
preceding operating systems. 

The iRMX 88 Executive provides fundamental 
multimasking software and complements the full- 
featured, multiprogramming iRMX 86 OS (ELEC- 
TRONIC DESIGN, March 15, 1980, p. 245). Through 
priority-based task scheduling, it concurrently 
monitors and controls multiple events. It provides 
real-time clock control, manages interrupts, and 
dispatches tasks. As an upgraded version of the 8- 
bit iRMX 80 Executive, iRMX 88 employs the same 
concepts and most of the same modules. Thus, the 


new OS offers field-proven and reliable interfaces. 


Tasks share resources 


The Executive will run with iAPX 88 or iAPX 86- : 


based boards and supports Intel’s iSBC 86/12A, iSBC 


88/40, and iSBC 86/05 single-board computers. Since 
it is fully configurable—not only procedure-by-pro- ; 


cedure, but also for all hardware addresses and 
interrupt levels—it also can be used with custom- 
designed boards that contain an iAPX 86 or iAPX 88 
processor, an 8259A programmable-interrupt con- 
troller, and 8253 programmable-interval timer, an 
optional 8251A programmable-communications in- 
terface, and—perhaps most important—an 8087 
numeric-data processor. 

In a multitasking system like the iRMX 88, several 


Jess M. Irwin, Project Leader 
Intel Corp. 
5200 N.E. Elam Young Pkwy, Hillsboro, OR 97213 
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tasks execute concurrently. A task is an independent 

program that shares system resources and com-— 
municates with other tasks. Each task has its own 
stack, where the registers used by the task are saved 
to shorten context-switching time. 

A task communicates with other tasks via 
messages, which convey data and synchronization 
information. These messages are channeled through 
data structures called exchanges. A task can send 
messages to an exchange (using the RQSEND pro- 
cedure) or wait for messages at an exchange (using 
the RQWAIT procedure). In the latter case, the task 
does not execute until a message is available or until 
a certain length of time has elapsed, specified in 
terms of “system time units” (minimum interval of 
real time recognized by the system). A task that is 


Suspended 


1: Task starts running because itis currently the ready task with the highest priority. 
2: Task is still ready but stops running PECause: it has no longer the highest priority. 
3: Task waits for a message. 

4: Task receives a Mesos 2 or one a delay" 

5: Task is suspended. oy 

6: Task is resumed. 

7: Running task suspends ‘self we 


1. Tasks inthe IRMX 88 Executive occupy one cffour states. 
Transitions are governed by the seven occurrences listed at 
the bottom of the figure. 
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not willing to wait may accept any message from 
an exchange (using the RQACPT procedure) if one is 
available; otherwise, the task remains without a 
message. 

Each task exists in one of four states: running, 
ready, waiting, and suspended (Fig. 1). A task is 
running if the processor is executing instructions on 
its behalf. It is considered ready if it is either running 
or able to run. A task is waiting if it has requested 
a message but has not received it. Finally, a task 
is suspended if some other task has specifically 
requested that it not be permitted to run. 

Each task has a permanent priority, which in- 
dicates its importance relative to other tasks in the 
system and to interrupts from peripherals. Priorities 
range from 0 to 255, with 0 being the highest priority. 
The “idle task” executes at priority 255 and prevents 
any other task at that priority from running. The 
ready task with the highest priority.is the running 
task. The software priorities correspond to eight 
hardware interrupts (Fig. 2). When the running task 
has a high priority, interrupt levels associated with 
equal or lesser priorities are masked off. 


Interrupts provide real-time access 


An interrupt invokes an interrupt-service routine, 
which either requests an end of interrupt (using the 


Software 


Hardware 


LevelO Highest 
1 priority 


16 
17 
32 
33 
48 
49 
64 
65 
80 
81 
96 
97 


112 
113 


128 
129 


Lowest 
255 priority 


2. Of256 interrupt levels, the top 129 are associated with . 
hardware. The remainder can be assigned to software tasks. 
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RQENDI procedure) or requests that a message be sent 
(using the RQISND procedure) to an interrupt ex- 
change associated with the active interrupt’s level 
(Fig. 2). In the latter case, an interrupt task waiting 
at the interrupt exchange would complete the inter- 
rupt servicing. The system can enable interrupts (via 
the RQELVL procedure) and disable them (via the 
RQDLVL procedure) and can set the interrupt vector 
associated with a given priority level (using the 
RQSETV procedure). 

The iRMX 88 treats interrupts as messages. When 
an interrupt occurs, the Executive creates a special 
message and sends it to the exchange associated with 
that particular interrupt. Should a previous inter- 
rupt message be at the exchange when the interrupt 
occurs, the message is changed to indicate a missed 
interrupt. Any task awaiting the interrupt exchange 
receives the interrupt message and is readied for 
execution. If the task has a priority corresponding 
to the interrupt level, it will become the running task. 
The task that was running when the interrupt 
occurred is still ready to run, but is pre-empted. 
When the running task relinquishes control by wait- 
ing at an exchange (possibly for another interrupt), 
suspending itself (via the RQSUSP procedure), or 
deleting itself (via the RQDTSK procedure), the 
iRMX 88 dispatches the next ready task. 

Interrupt-processing tasks are simply tasks that 
wait at interrupt exchanges. They do not need to save 
the interrupted task’s state or control the interrupt 
hardware. A task may simulate an interrupt by 
sending a message to an interrupt exchange (using 
the RQSEND procedure). 

Because the iRMX 88 imposes some software 
overhead, a direct interrupt-servicing facility is pro- 
vided for those cases where interrupt response time 
is critical. The interrupt vector is set with a pointer 
to an interrupt-service routine (using the RQSETV 
procedure); then all interrupts occurring at that level 
are handled by the interrupt-service routine; which 
is also responsible for all interrupt-logic control and 
state-saving. To complete the interrupt, the routine 
must use the RQISND or RQENDI procedure. 


Creating tasks and exchanges 


The iRMX 88 supports the dynamic creation of 
tasks and exchanges, as well as their deletion when 
they are no longer needed. Creating a task (with the 
RQCTSK procedure) places the new task on the 
system’s list of ready tasks, according to its priority. 
The creation of an exchange (using the RQCXCH 
procedure) results in the initialization of an “empty” 
exchange—one that has no waiting messages or 
tasks. The deletion of a task (via the RQDTSK pro- 
cedure) results in its removal from all system lists. 
The deletion of an exchange (using the RQDXCH 
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procedure) is only possible if no messages or tasks 
are waiting at the exchange. 

Suspension of a task (using the RQSUSP procedure) 
places the task on a list of suspended ‘tasks and 
removes it from. the list of ready tasks; to return 
the task to the ready state, the RQRESM procedure 
must be used. 


A coprocessor for Stal crunching 


Unlike previous operating systems, the iRMX-88 
can support the 8087 numeric-data processor (NDP) 
in a way that is invisible to the user. When an NDP 
task is created, the iRMX 88 initializes and maintains 
the state of the 8087 in a save area. Should an 


Interrupt 


Interrupt 


3. Interaction between the terminal and a user task Involves 
several IRMX 88 exchanges (gray). Some serve for Inputs from 
the keyboard (top); others, for outputs to the CRT (bottom). 
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Free 
' space 
manager 


4. When auser task needs a block of RAM, exchange rarsax . 
passes the request to the free-space manager, which sends 
an acknowledgment via respsex. The Rarsrx exchange serves 
to release the block. 


DESTINATION: 
1.0000 METERS 
4.0000 METERS 
5.0000 METERS 


POSITION: 
X = 1.2000 METERS 
Y = 3.4000 METERS 
"2% = 2.1000 METERS 
‘VELOCITY: 
DX =-C.0050 METERS /SECOND 
DY = 0.0800 METERS/SECOND 
DZ = 0.0500 METERS/SECOND 


capes VELOCITY: 
0.0100 METERS/SECOND 

0.1000 METERS/SECOND . 

0.0500 METERS/SECOND 


5. The arm of an Industrial robot can move in three directions: 
X, Y, and Z. The console display reports current position and 
velocity (left), as well as the limiting values (right). . 


unmasked error occur in the 8087, an interrupt is 
generated on a configurable level. Using the default 


_interrupt-service routine, the iRMX 88 sends an. 


interrupt message to the interrupt exchange; the 
user can then supply his own error handler. The error 
task must specify itself as a non-NDP task or the 
system will deadlock. But the error interrupt, if used, 
must not be masked off. 

The Executive includes a terminal handler which 
establishes real-time asynchronous serial com- 
munication between an operator’s terminal and the 
tasks running under the executive (Fig. 3). The 
terminal handler provides a simple operator in- 
terface, which includes line-editing features, a 64- 
byte type-ahead buffer, and control over the output. 

Since all port addresses and interrupt levels for 
the terminal handler are configurable, it supports 
any component configuration using an 8251A 
programmable-communications interface with an 
8253 programmable-interval timer for baud-rate 
generation. A task interfaces with the terminal 
handler through two exchanges, where messages are 
sent to initiate read and write requests; they are 
processed on a FIFO basis. Characters are read and 
written in response to interrupts from the 8251 
programmable-communications interface. Each re- 
quest results in the transmission of one line to or 
from the terminal. Read requests are sent to the 
RQINPX exchange, and write requests to the RQOUTX 
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exchange. When a request has been serviced, its 
message is sent to the specified response exchange. 


The iRMX 88 also contains a free-space manager, . 


which maintains a pool of free RAM memory (Fig. 
4), Tasks request blocks of memory from the pool 
and return blocks to the pool. The request is made 
by sending a message to the manager’s allocation 


exchange, RQFSAX, specifying the length of the 


needed block. If sufficient contiguous free RAM is 
available, the requesting task receives a message 
acknowledging the request and supplying the ad- 
dress of the block in the form of a message. Other- 
wise, the requesting task receives a message indicat- 
ing how much free RAM can be allocated. The 
requesting task may then ask for a smaller block. 
In either case, the response from the free-space 
manager is returned in the same message that was 
used for the request. If the task must have the block 
of memory, it makes an unconditional request; the 


$title (‘display algortinm') 
‘ display: 


00; 

$include(:f3: ied. lit), 
$include(:fl:rqisnd.ext) 
$include(:fl:rqendi.ext) 
$includel :fl:rqwait.ext) 
$Sinclude(:flirqsetv.ext) — 
$include{ :fl:rqelvl.ext) 


DECLARE display$ied int$exchange$descriptor PYBLIC; 


/* display interrupt service routine */ 
display$isr: PROCEDURE INTERRUPT 63; 
/* check for proper interrupt */ 
OUTPUT (rq$8259a)}=Opbh; 
IF NOT ({ INPUT(1rq$8259a) AND 80h) = 0) THEN 
D0; 
/* output next character */ 

' QUTPUT(rq$th$8251) = output$buffer(output$ index) ; 
output$index = output$index + 1; 
output$count = output$count - 1; 

IF output$count = 0 THEN 
CALL rq$isnd( .display$exchange) ; 


E 
CALL raq$endi(.display$exchange); 
END display$isr; 


display: PROCENURE ; 
DECLARE message$address ADDRESS; 

"CALL rq$setv( .display$isr,display$level); 
OO FOREVER; 


/* copy monitor and control information into the display 
buffer with tne template of the display */ 


output$index = 1; ; 
output$count = LENGTH(outputSbuf fer); 
/* enable the display interrupt and wait until the 
buffer has been output */ 
CALL ragelvi(.display$ied); 
message$address = rq$wait(.display$ied,0); 
END display; 


6. The PROCEDURE DISPLAY (bottom half) Illustrates how the 
IRMX 88 operating system deals with random events. Here, 
interrupt level 63 has been chosen by the user. 
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free-space manager then lets the requesting task 
wait until sufficient memory is available. When a 
block of RAM is no longer needed, it may be sent 
to the reclamation exchange (RQFSRX) where it is 
merged into the free-space pool. 


The building-block approach 


The iRMX 88 Executive is completely configurable. 
The minimum “nucleus” consists of the following 
procedures: RQSTRT (initialization), RQCTSK (task- 
creation), RQCXCH (exchange-creation), RQSEND, and 
RQWAIT. Any of the remaining procedures are auto- 
matically included when they are referenced. Inter- 
rupt support and the system clock are separately 
configurable. The port addresses used for the 8259A 
programmable-interrupt controller, the 8251A pro- 
grammable-communications interface, and the as- 
sociated 8253 programmable-interval timer are con- 
figurable to any iAPX 86 or iAPX 88 port address. 
The transmission rate of the terminal handler is 
configurable from 150 to 19,200 baud. The interrupt 
levels for the system-clock and terminal-handler 
interrupts are configurable to any level of the 8259A 
programmable-interrupt controller. Any unused 
level is configured to its default interrupt-service 
routines. The base of the interrupt vector used by 
the 8259A programmable-interrupt controller can be 
selected from interrupt levels 8 to 248. The smallest 
system time unit is 1 ms. 

An “interactive configuration utility” (ICU 88) 
simplifies the configuration process. This utility, 
which executes on the Intellec microcomputer-de- 
velopment system, asks the user a series of ques- 
tions, allowing him to specify his own board con- 
figuration or to use a default that corresponds to the 
iSBC 86/12A, iSBC 86/05, or iSBC 88/40 boards. 

To transfer an application from the iRMX 80 to 
the iRMX 88 Executive, the user must change the 
parameter for the create-task (RQCTSK) procedure 
from a 16-bit address to a 32-bit pointer. The descrip- 
tion of the task can then be placed in random-access 
or read-only memory. In the iRMX 88, the definition 
of task has been expanded to incorporate a flag that 
indicates whether or not the 8087 numeric-data 
processor will be used. If that flag is set, an additional 
94 bytes must be reserved for the task. Furthermore, 
the first parameter of the set-vector (RQSETV) pro- 
cedure must be changed to a 32-bit pointer. 


A robot demonstrates Implementation | 


The iRMX 88 Executive demonstrates its value in 
a typical application: controlling an industrial robot’s 
arm. The position of the arm in each of three 
dimensions is measured by an analog voltage on 
three input lines. The speed and direction of move- 
ment in each dimension is controlled with an analog 
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input: PROCEDURE; 
/* initialize */ 


DO FOREVER; 
60 CASE field + 1; 
/* next x position */ 
00; 
/* convert the Character ang in the input buffer 
into a real number * 


CALL rq$send( .control§$x$ed, 
.xsposition$message); 
ENO; 


END input; 
END input; 


7. An endless loopis atypical method for capturing input. 
The skeleton code for PROCEDURE INPUTShows the Interface with 
the executive via a caLLto an OS procedure. 


$title (monitor algortinm') 
SS Rae ee 


GE 7 
message$address ADDRESS; 
CALL rqgcxch{ mean Inge ra) s 
00 FOREVER; . - 
é ragwait(. waitingsed, 16); 


aac bC OMMA =. XS 
age$address = rq$acpt{ vwatt ingged) 
ontrol$input = SHR( INPUT (adc$ low), 4) + 
SHL( INPUT(adc$high), 4)5. 
x$monitor$position = x$control$input * xSinput$scale; 
x$rate = ( x$position - x$monitor$position 33 Ws se 
noe RESET TON = XGmMONTCOrSpas Teeny aa area, 
ary CALL ra$send( .x$action$ed,. Fe Aciaisiezesce): 

END;. 
END nonitor$x; 


a CR ee CO Oe ee 


ENO. monitor; 


8. PROCEDURE MONITOR Sxis a task that has to run every 16 ms. 
The IRMX 88 procedure nawamaccepts the desired time delay 
as an argument. 


$title (‘control algorithm’) 
control: 
00; 
/* control x task */ 
control$x: PROCEDURE ; 
DECLARE message$address ADDRESS ; 
DO FOREVER; 
nessage$address = rq$wait(.x$action$ed,0); 
x$control$current = max$x$rate * 
( next$x$position - x$position ) / ABS( next$x$position 
- last$x$position }; 
x$control$output = SHL( FIX ( 
x$control$current * x$scale ), 4) + x$output$select; 
QUTPUT(dac$nigh) = HIGH(x$control$output) ; 
QUTPUT(dac$low) = LOW(x$control$output); 
END; 
END control$x; 


END control; 


9. This control algorithm sends data to the robot arm’s X- 
axis through a d-a converter. The task remains dormant until 
the INPUT procedure from Fig. 7 makes It up. 
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current on three output lines.. 

The hardware consists of an iSBC 88/ 40 board with 
an iSBC 337 high- -speed math multimodule, an iSBX 
328 analog-output multimodule, and a CRT terminal 
with an RS-2382 serial interface. The position of the 
arm in any dimension is read from the a-d converter 
on the iSBC 88/40; the converter is multiplexed over 
the three analog inputs. The d-a converter on the 
iISBX 328 analog-output multimodule is multiplexed 
to control the current to three stepper motors, which 
in turn control the arm’s motion. A display (Fig. 5). 
is maintained on the CRT terminal and gives the 
robot’s current position in three dimensions, the rate . 
of change in each direction, and updatable fields for 
the desired position, as well as the maximum rate 
of change in each direction. 

The display algorithm (Fig. 6) continuously up- 
dates the display from the control and monitor data 
bases. The monitor and control data bases update 
the display buffer. The display task initializes the 
display index and display count, enables the display 
interrupt, and waits at the display-interrupt ex- 
change. The display-interrupt service routine re- 
sponds to display interrupts by outputting the next 
character from the display buffer. When the last 
character in the display buffer has been output, a 
message is sent to the interrupt exchange; otherwise 
an end-of-interrupt is sent. 

The input algorithm (Fig. 7) accepts digits as they 
are typed on the CRT terminal and enters them into 
the control field being updated. The fields on the 
right-hand side of the display are updated, starting 
with the top field and progressing to the bottom. 
Entry of a carriage return causes the values in the 
updated field to update the control-data base; the 
input algorithm then proceeds to the next field. 
Backspace discards the last digit typed. All other 
characters are ignored, and the user cannot type 
outside the defined fields. The input-interrupt rou- 
tine receives a character with each interrupt and 
copies it into the display and input buffers. 

The monitor algorithm (Fig. 8) samples the posi- 
tion of the robot’s arm 60 times per second. It updates 
the monitor data base and then signals the control — 
program through the appropriate exchange. | 

The control algorithm (Fig. 9) waits at the proper 
exchanges for a message from the input or the 
monitor algorithms. It then outputs a control current 
to the d-a converter based on the relative position 
of the robot’s arm.O 
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I. INTRODUCTION 


The introduction of the single board computer as a 
tool for the system designer has opened the way for 
many varied application areas to benefit from the 
advantages of computer utilization. A problem still 
exists, however, because the available I/O con- 
figurations have been largely incompatible with the 
wiring and packaging techniques required in indus- 
trial environments. This problem is Overcome by 
the utilization of the Intel® iCS™ product family, 
The purpose of this application note is to provide a 
representative approach to the implementation of a 
computerized solution to an industrial control 
system. 


System Description 


This application note will deal with a control 
system which will regulate the temperature in each 
of four ovens. Each oven will be defined as utiliz- 
ing a light bulb for heating. Normal convection will 
be used to provide cooling. The internal tempera- 
ture will be measured by means of a thermistor in- 
stalled in each oven. We will assume that we will be 
required to implement some type of operator panel 
near the ovens which will allow the status of each 
oven to be monitored. This approach is similar to 
many common industrial applications which re- 
quire a supervisory control station in one area and 
a separate operator interaction panel near the 
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equipment being controlled. The setpoint and tol- 
erances should be input from an external location. 


With these facts about our system defined, we can 
begin a step by step solution to providing a com- 
puterized control system to operate the ovens. We 
will discuss the various equipment trade-offs and 
the decisions which will be used to define the hard- 
ware/software designs. | 


Control Algorithm 


Before we can begin the design of our system, we 
must have a clear idea of the technique we will use 
to control the system. Our control system must 
maintain the oven temperature within a predefined 
and fairly narrow range of the setpoint. Let us 
make an assumption that the light bulb will be con- 
trolled digitally, meaning that the bulb must either 
be turned fully on or it must be turned fully off. 
The obvious control technique then becomes turn- 
ing the bulb on when the temperature of the oven is 
below our lower limit and turning the bulb off 
when the temperature is above the higher limit. It 
seems reasonable to assume that this technique will 
provide a temperature in the oven which varies 
sinusoidally with time. This is true because even 
though the lamp is turned off, it will continue to 
generate heat for a short period of time. Likewise, 
when the bulb is turned on, it will not instantly be 
able to provide heat to raise the temperature of the 
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chamber. We would expect to havea system re- 
sponse such as is shown in Figure 1. A_ better 
method of control can be devised if we provide 
some type of temperature prediction into our con- 
trol algorithm. Since this utilizes the rate of 
temperature increase or decrease, it will involve a 
type of derivative control system. This derivative 
control action will tend to dampen the temperature 
oscillations which might be encountered if only an 
instantaneous on-off control system were utilized. 
Figure 2 shows the response with time that we 
might expect with this type of control system. 


ON-OFF CONTROL 


TEMPERATURE 


TIME 


Figure 1. Maximum Effort Current Temperature — 


- DERIVATIVE CONTROL 


TEMPERATURE 


TIME 


Figure 2. Maximum Effort Projected Temperature 


The second approach is superior to the first 
because the control will provide a much smaller 
oscillation of the oven temperature. Other solu- 
tions are possible, such as providing a modulated 
output to the lamp. However, in an attempt to pro- 
vide a simple model upon which to expand our 
system solution, we will assume that the second ap- 
proach will provide us with an accurate enough 
control of the oven temperature. 


Having made the decision as to the control] tech- 
nique, we can proceed with the task of determining 
the general system configuration. That is, we can 
define the physical system characteristics and the 
components to which we must interface the com- 
puter system. This approach is identical to that 
which would be used in a conventional control 
system design. 


Basic System Configuration 


Based upon the data which we have provided so 
far, it is possible to build a block diagram: of the 
system’s major components. The. system consists 
of four Ovens, an operator’s panel, a data entry 
panel, and the actual control logic. A block dia- 
gram for the system is shown in Figure 3. We must 
now further define the elements which make up 
each of these blocks. 


OPERATOR 
~~ PANEL 


| OVEN 2 


| 


OVEN 3 


CONTROL 


Figure 3. Application Block Diagram 


Each oven must consist of a heating element, which 


we have already defined as being a light bulb, anda 


- temperature sensing element which we have said 
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will-be a thermistor. Each heating element will be 
switched on or off by applying or removing a 
source of 115 VAC. The thermistor temperature 
can be sensed by using the thermistor in a voltage 


divider circuit. We can then measure the voltage 
across a fixed resistor to obtain an analog signal 
which is proportional to the oven temperature. We 
will determine the required value of the fixed 
resistor at a later time. 


The operator’s panel should be designed to provide 
the workfloor operator with basic information as 
to the status of each oven. It should also allow 
some method by which he can inhibit the operation 
of any oven should it become necessary for charg- 
ing or servicing the oven. We can then define the 
basic elements which should make up the opera- 
tor’s control panel. Each oven should have associ- 
ated with it the following controls and indicators: 


1. Oven ON/OFF Switch — This switch will allow 
the operator to inhibit the oven operation by 
turning the appropriate oven switch to OFF. 


2. Oven RUNNING Indicator — This indicator 

will provide a visual indication that the oven is 

activated and that the temperature is being con- 
trolled. | 


3. Oven IN TOLERANCE Indicator — This indi- 
cator will turn on when the oven temperature 
falls within the allowable bandwidth around the 
setpoint for that oven. 


4. Oven ALARM Indicator — _ This indicator is the 
complement of the in tolerance lamp. It will be 
turned on when the oven is activated and the 


temperature does not lie within the desired 
bandwidth. 


5. Oven CAUTION Indicator — It may be neces- 
_ gary to alert the operator to a potential oven 
temperature control problem before it actually 
occurs and sets off the alarm indicator. Since we 
have defined our control algorithm as utilizing a 
type of derivative control, we can project the 
oven temperature ahead in time. We will turn 
the oven caution indicator on when we predict 


that the oven temperature will lie outside of the | 


desired bandwidth in a predetermined future 
time period. 


We have now defined the operator interface which 
we will utilize to control and monitor the oven 


processes. 


At this point, we will make a decision that the in- 
terface used to input the setpoints will utilize a 
CRT terminal. Though the decision may seem to be 


completely arbitrary, we will see later that CRT ter-- 


minals provide an extremely useful device for 
allowing an operator to communicate with the sys- 


tem. Once the decision has been made, we have no 


further requirements to consider hardware design 
for this terminal, as the entire operation can be 
handled in the software development which will be 
considered later. 


A common technique for documenting a system is 
the ladder diagram. At this time, we can construct 
a ladder for our control system. Unlike conven- 
tional design techniques, our ladder diagram need 
only be concerned with the actual drive and sensing 
circuits since the logic required to drive the various 
outputs will be defined using software. This results 
in a considerable simplification of the design pro- 
cess.. A ladder diagram for a typical oven is shown 
in Figure 4. We can defer the implementation of 
the control algorithm until we begin to develop the 
software portion of our control system. It is now 
possible to complete the external hardware design 
and to implement the system wiring package. 


1 1 
2 O+——___ wire LABELS) ql 


+5V 


ANALOG 
TO 
DIGITAL 
CONVERTER 


Figure 4. Ladder Diagram of One Oven 


Il. WIRING INTERFACES 


A major pitfall in utilizing a computer for control 
systems has traditionally been the requirement for 
the design engineer to expend a considerable 
amount of his time in designing interfaces to con- 
nect the physical wiring to the computer system. 
The introduction of Intel’s product line of termina- 
tion panels has essentially, eliminated the require- 
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ment of designing interfaces and allows more engi- 
neering time to be spent providing a solution to the 
application. _ Before we continue with the specific 
design, we should spend some time discussing the 
various types of termination panels available and 
the general characteristics of each panel. 


Analog Termination Panels 

The Intel® iCS 910™ Analog Termination Panel 
has been designed to provide a simple means of ter- 
minating the analog wiring and of providing an 
interface to the control system input/output. All 
wiring is terminated utilizing pressure type screw 
barrier blocks. Termination blocks have been pro- 
vided to allow the termination of up to 32 single- 
ended or 16 differential channels of analog input. 
For use in a differential input environment, such as 
we will be using, the terminator blocks provide wir- 
ing terminations compatible with shielded cable in- 
puts in that provision has been made to accept the 
shield of each input signal. The shield is then car- 
ried through the on-board circuits to the analog-to- 
digital converter. Provision has been made on the 
board for the mounting of commonly used circuits 
for signal conditioning. The available signal.condi- 
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Figure 5. iCS 910™ Analog Terminator Panel Assignments 
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Figure 6. Typical Circuit on Analog Terminator 
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termination resistors and the installation of a single 
pole low pass filter network. The basic barrier 
assignments for the iCS 910 termination panel are 
shown in Figure 5. The possible circuit networks 
for this panel are illustrated in Figure 6. A com- 
plete description of the analog termination panel 
can. be found in the iCS 910 Analog Signal Condi- 
tioning/Termination Panel Hardware Reference 
Manual (manual order number 9800800A). 


The functions of the analog termination panel will 
become more clear as'we develop the actual config- 
uration required to support our oven application. 
Referring to the ladder diagram (Figure 4) we see 
that a fixed resistor is necessary to provide the volt- 
age divider network to sense the oven temperature. 
The current termination resistor (Rc) on the 
iCS 910 board can be used to provide a convenient 
mounting location for this component (refer to 
iCS 910 circuit schematic, Figure 6). At this point, 
we must make a design decision regarding the uti- 
lization of a low pass filter for our analog circuits. 
Since the oven temperatures are not expected to ex- 
hibit rapid fluctuations with time, the use of a low 
pass filter will not adversely effect the temperature 
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sensing. Indeed, the use of a low pass filter should 
contribute to spurious signal rejection should the 
analog cables pick up external noise signals. Calcu- 
lations will show that the use of a filter network 
consisting of 11K ohm series resistors and a 2.2 pF 
capacitor will provide the filter characteristics 
shown in Figure 7. 


6 dBIOCTAVE 


0.1 — 41 10 . 100 1000 


FREQUENCY (Hz) 


Figure 7. Single Pole Filter Characteristics 


Based upon our requirements and using the circuit 
schematic of Figure 6, we can provide the circuit 
interfaces required by our ladder diagram (Figure 
4) by configuring the channels of the iCS 910 ter- 
minator as shown in Figure 8. This results in a sim- 
ple two-wire per oven analog interface. The termi- 
nator board is designed to connect to the various 
analog I/O boards by means of a standard ribbon 
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cable which is supplied with the terminator panel. 
The actual selection of the appropriate analog 
board will be deferred until later. We will define 
that oven number | will correspond to the differen- 
tial analog channel 0; oven 2 will correspond with 
channel 1; oven 3 will correspond with channel 2; 
and oven 4 will use channel 3. This leaves 12 analog 
differential channels available for future expan- 
sion. The channel selection just made was a purely 
arbitrary choice. 


THERMISTOR 


Figure 8. Analog Circuit for Oven Application 


The wiring to the iCS 910 terminator panel can 
then be made essentially as shown in Figure 9. 
Clearly, the use of the terminator panel greatly 
simplified the connection between the control sys- 
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tem and the physical devices which are 2 to be moni- 
tored or ‘controlled. Figure 10 shows the placement 
| of the components onto the board. 


Figure 10. Analog Terminator Component Locations 


Low Voltage Digital Termination Panels 


Looking again at our ladder diagram for an oven 
control system (Figure 4), we see the need to pro- 
vide a second type of interface ‘signal. This. is to 
provide the switching for the various indicator 
lamps used on the operator’s. control panel. Tradi- 
tionally, this interface has been handled by using 
electromechanical relays. The coils would be driven 
by the low. voltage control system. and the relay 
contacts were used to drive the external indicators. 
Modern technology provides us with a solid state 
device to perform the same function, the optical 
isolator. We can use these devices to provide a 
highly reliably and low cost alternative to the relay 
interface. The Intel® iCS 920™ Digital Signal Con- 
ditioning/Terminator Panel provides us with a 
convenient vehicle for mounting the optical 
isolator circuits and for terminating the wiring 
associated with the indicator devices. 


The iCS 920 panel is designed’ to be. used: i. thiose - 


| interface circuits which incorporate operating volt- 
_ages less than §0 volts and which generally use cur- 
rents which are smaller than 300 mA. These limits 
-are given only for a general guideline since a wide 
‘variety of optical isolators and drivers are available 
for use on the board. Some of the devices are 
capable of handling greater voltages or currents. A 


The digital panel provides terminations. ‘for. up to 


24° digital: channels, each of: which can be con- 
figured as ‘either an input or an output channel ac- 
cording to ‘the ‘specific application requirements. 
A8 with the analog termination panel, all wire ter- 
minations are made using pressure type barrier 
strips which will accept up to 16 gauge wire. The 24 
digital channels correspond with those input/out- 
put channels assigned to the standard Intel I/O 
configurations used on the single board computers 
and I/O expansion boards. We will dwell more on 
this subject later when we define the addresses 
associated with éach circuit which we desire to in- 
corporate into the termination panel. 


Since the digital channels can be configured into 
either an input or an output mode, it is wise to dis- 
cuss each configuration so that a clear understand- 
ing of the board can be obtained, even though our 
application example will only use the output mode 
with this board. 


Figure 11 provides a schematic of the panel when it 


is configured for.a. digital input mode. To set up a 


channel to operate as an input, it is necessary to 
add at least two jumpers ‘to the wire- -wrap jumper 
posts. As can be seen, pins 6. and 4 must be con- 
nected together as well as pins 3 and 5. ‘If the board 
is to provide a visual LED indication of the channel 
status, an additional | jumper should be installed 


between f pins | and 2 of the jumper posts. If this is 


done, be certain to take into account the additional 
current requirements when calculating the required 
input resistors. Two resistor mounting locations 
are provided to allow installation of selected comi- 
ponents to handle the current limit through the 
optical isolator (Rx) and:the threshold voltage for 
turn-on of the device (Ry). A complete and de- 
tailed procedure for selecting these resistors based 
upon the input voltages is provided in the iCS 920 
hardware reference manual mentioned earlier. Pro- 
vision has also been made on the termination panel 


for’ the installation of a'diode (CR) ‘to ‘protect 


| against reverse bias application. 


The components have been laced on the board ar- 


_ representative list of available devices and com- .. 


plete details of the termination panel aré available ~~ 


in the iCS 920 Digital Signal Conditioning/Termi- 


nation Panel Hardware Reference Manual manne: 


order number 9800801A). 


ranged in groups of two channels. This eases the 
task of finding various components or of locating 
the holes for installing the required components. 
This layout is illustrated in Figure 12. It is impor- 
tant to take note of the physical placement of the 
optical isolator chips i in the 20-pin socket. This i in- 


stallation location must be followed rigorously 


when using a channel in an input mode. Also take 
note that provisions are provided for mounting two 


sizes of resistors in location (Rx). This will accom- 
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modate the power dissipation requirements which 
will be encountered in various application situa- 
tions. Referring again to Figure 12, note that the 
upper half of the layout represents odd channels 
and the lower portion of the layout is used for even 
channel component mounting. 


Figure 11. iCS 920™ Digital Terminator Input 
Configuration | _— : 


When the iCS 920 panel is used in this input mode, 
it corresponds to the utilization of a relay coil to 
sense some external contact closure. The resistors 
can be thought of as selecting the coil’s operating 
voltage and the diode provides the same transient 


Figure 12. Digital Terminator Input Parts Layout 


protection function as when installed on an electro- 
mechanical relay. Finally, the optical isolator out- 
put corresponds to the contacts associated with the 
relay coil. As we will see later, this approach pro- 
vides us with an unlimited number of contacts per 
relay coil. 


The oven application requires a contact for driving 
the indicator lamps associated with each oven. If 
we define the driving voltage to be 24 volts DC, we 
will find that the voltage and current requirements 
fall within the limits specified for using the iCS 920 
Digital Signal Conditioning/Termination Panel. 
Let us examine in more detail how this can be ac- 
complished. 


We will select an industrial indicator assembly 
which utilizes a full voltage 24-volt lamp. Typical 
lamps would be type 387. This will require a drive 
of 40 mA at 28 volts. Our switching device must be 
capable of driving this load. The analogy used 
earlier to compare the optical isolator with a relay 
in an input mode holds true when we utilize the 
devices in an output configuration. If we examine 
the data sheet for the current switching character- 
istics of a typical optical isolator, say the TIL 113 
(Appendix A), we can see that the current and volt- 
age requirements fall well within the allowable 
ratings of the device. We have selected the relay 
contact characteristics! We need not concern our- 
selves with the. selection of current limitation 
resistors (coil voltage ratings) since this circuitry is 
provided on the terminator panel when a circuit is 
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configured in an output mode. If we refer to Figure 
13, we can see the-on-board schematic for the‘out- 
put drive mode of operation. Two jumpers must be 


installed for each output channel. The first, be-: 


tween-pins | and 2, is used to enable the LED chan- 
nel status indicator. The second, between. pins 3 
and 4, actually connects the computer generated 
drive signal to the input of the. optical isolator 
(analogous to connecting the relay coil to the driv- 
ing line): Provision has been made on the circuit 
board for only one optional component in the out- 
put mode; this is the resistor (Rz).: This component 
has the effect of increasing the response time of the 
switching device. Because our indicator lamps are 
not time critical, we will choose to omit the instal- 
lation of this component. 


CPU OUTPUT 
PORT 


Figure 13. iCS 920™ Digital Terminator Output c Circuit 


Figure 14 sievides a drawing showing the location 
of the components on the iCS 920 panel when it is 
utilized as an output switch. Again note the place- 
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Figure 14. Digital Terminator Output Configuration 


3-12 


ment of the optical isolators .in the 20-pin sockets. 
Also note the jumper arrangement used to ae 
the required output circuitry... 


Again referring to Figure 13, we'see’ ‘that an alter: 
native to using ‘the optical isolator for a switch 
exists. Provision hasbeen made-on.the: panel ‘for 
the installation of high power buffer/driver chips 
such as the TI 75462. This device provides the same 
coil/contact characteristics as our optical isolator; 
however, no isolation between the input and out- 
put is provided. In certain applications, this con- 
figuration may be desirable and can be imple- 
mented by connecting jumpers | and 3 together, 
then placing a Jumper block in the isolator socket 
location. The oven application will not use this 
mode because of the many edvantanes which isola- 


tion can provide. | 


Prior to actually installing the components: ents 
the iCS 920 panel, it is necessary to assign the 
lamps to definite channel addresses. This involves 
making some additional assumptions and. design 
configuration decisions. If we consider the total 
number of digital inputs and outputs which are re- 
quired to handle all four ovens (including the as yet 
unconsidered switch and heater signals), we see 
that a total of 24 channels will be required. These 
will be broken out as.shown below: 


; No. of - Roe ge ae, a 
Channels Type ‘Function ae 
16 —-DC.:: Ovenindicator lamps: 
4S AC... Oven heaters.» 
4 AC... Oven RUN switches. 
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We have indicated that the 16 indicator lamps can 
be handled using the iCS 920 panel. An examina- 
tion of the data sheets for the various Intel single 
board computers and expansion boards provides us 
with the fact that a common characteristic of most 
boards is the use of at least one Intel 8255 Pro- 
grammable Peripheral Interface. This provides us 
with at least 24 I/O lines with which to work on 
each single board computer. We can'‘then assume 
that we will not require an I/O expansion board to 
implement our application. Ideally, we can handle 
our total requirements with one parallel interface. 


The various Intel parallel ports are brought off of 
the computer and. expansion boards. using edge 
connectors. These edge connectors are then con- 
nected to the termination panels using a standrd 
ribbon cable assembly, effectively providing an ex- 
tension of the I/O ports out to the termination 
panels. The 24 channels are grouped into three I/O 
ports (each consisting of 8 channels or bits) which 
are then called port A, port B, and port C. When 
connected to the iCS 920 panel, these ports and 
their bit assignments will be as shown in Figure 15. 


At this point, we seem to be in a dilemma since we 
would like to use all 24 channels and we have used 
only 16 of them on our panel while we have utilized 
the edge’ connector of the interface. It would be 
desirable to have some technique to extend the 
other 8 channels to a high voltage terminator 
panel. It might be well to interrupt our channel 
assignments at this time to jump ahead and con- 
sider the features of the iCS product line which will 
enable us to accomplish our interface desires. We 
will then consider the interface of the high voltage 
signals to our control system before returning to 
the problem of assigning port locations to our 
lines. 


Figure 15. iCS 920™ Digital Terminator Port Assignment 


High Voltage Digital Termination Panels 


The Intel® iCS 930™ AC Signal Conditioning/ 
Termination Panel is designed to interface up to 16 
AC signals (up to 280 volts at 3 amps) or high cur- 
rent DC signals (up to 50 volts at 3 amps) to the 
parallel ports of the Intel single board computers 
or I/O expansion modules. The barrier strip termi- 
nations on this panel are designed to easily handle 
the 14 gauge wire commonly found in applications 
requiring the use of the AC terminator. 


Solid state relays are used to provide the interface 
between the computer I/O ports and the physical 
plant devices. These devices make the utilization of 
the panel a simple task once a ladder diagram of 
the required circuits has been drawn. As we have 
previously mentioned and as Is clear from looking 
at Figure 4, we shall need to utilize eight of the 
available circuits, four for input and four for out- 
put. The implementation of each signal type re- 
quires only that we insert the correct type of solid 
state relay into the appropriate socket. 


First, consider the input configuration which is 
required to sense the position of the oven RUN 
switches. Figure 16 shows the circuit schematic 
when used in the input mode. We can see that the 
output signal will turn on when the input power is 
applied. Like the digital termination panel, each 
circuit’s status is indicated by means of an LED in- 
dicator installed on the board. The input circuit ts 
protected by a socketed 3-amp fuse which may be 
replaced without the need to solder any compo- 
nents. The solid state relay used for this configura- 
tion should be a type LACS which is available from 
either Opto-22 or Motorola. Complete details of 
available relays and their uses on the board are 
available in the iCS 930 AC Signal Conditioning/ 
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Termination Dane Hardware Reyerence Manual» 


(manual order number. 9800802A). Keep _ in mind 
the fact that although this application note repre- 
sents the solid state relays as being actual relays and 
contacts, they in fact are solid state and contain no 
moving parts. 


Figure 16. iCS 930™ AC Terminator Input Circuit 


The output configuration is utilized to turn the 


heater elements (the light bulbs) on and off. Figure. 


17 provides us with a schematic of the output cir- 
cuitry. In this case, we will insert a solid state relay 
of type OACS which will handle up to 140 volts 
RMS at 3 amps. In some cases, it might be desir- 
able to add certain components to the terminator 
panel when using it in the output mode. Two possi- 


ble circuit configurations are possible. The first 


and perhaps the most common will consist of in- 
stalling a MOV (metal oxide varistor) across the 
solid state relay contacts. This will be required 


when the load being driven is inductive i in order to_ 


prevent the transients generated by the load from 
damaging the triac in the SSR (solid state relay). 
Since the SSRs utilize zero voltage switching and 
the load in our ovens is resistive rather than induc- 
tive, our application will not necessitate the instal- 


lation of this device. The second possibility for ad-_ 
ditional circuitry also involves driving inductive -° — 


loads. When the load is highly inductive, a possi- 


bility exists that reliable operation of the SSR may 
not occur because of incorrect values for the dv/dt . 


(a complete description of ‘this phenomenon is 
available in various publications available from the 
manufacturers of the solid state relay devices). 
Provision has been made for installation of an ex- 
ternal snubber network should this be required. 
Again, our oven control system will not require this 
type of circuitry. Figure 18 is provided for refer- 
ence should the reader desire to see the location of 
the additional components on the panel. It should 
be noted that the component placement does not 


allow the it seaiedian of the MOV rang ne sau bbe: 
simultaneously. 
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Figure 18. AC Terminator Component Locations 


We can now get back to the task of assigning ad- 
dresses to the various digital channels. The iCS 930 
panel has three connector options for connecting it 
to the computer’s I/O ports. The standard con- 
figuration utilizes connector J2 to attach the rib- 
bon cable assembly. When this is done, the com- 


‘puter ports A and B will correspond to the 16 chan- 


nels on the terminator panel (Figure 19). If we look 
at the termination panel, we will see that there is a 
provision for the user installation of two additional 
ribbon connector sockets onto the board, These 
are used in order to utilize the computer port C. If 
connector J3 is installed and utilized instead of J2, 
the channel assignments will be as shown in Figure 
20. In a similar manner, connector J1 can be in- 
stalled and utilized to provide connections between 
the computer port C and the other eight SSR posi- 
tions. If we choose the 16 lines required for driving 
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the indicator lamps from the iCS 920 panel to be 
ports A and’B; then it seems reasonable to, assign 


the eight remaining lines required on the iCS 930 to: 


port C. A feature of utilizing standard ribbon cable 
assemblies is the ability to easily add ribbon plug 
connectors to the cable.. This. will result in an’ 
assembly transferring ports A, B and C to the iCS 
920 panel (however, port’C is not used) and which | 
continues the port C signals to the iCS 930 panel. © 
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Figure 20. iCS 930™ AC Terminator Port Assignments 
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Individual channel assignments can now be made, — 
grouping the inputs and outputs together in groups - 
of. four (this is done because of a requirement of 

the single board computers to share terminator and 

driver component packages in groups of four). Fig- 

ure 21 provides a drawing showing the channel 

assignments: and the physical wiring locations 

which will be used to connect the oven heaters and 

switches, su | 
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Figure 21. iCS 930™ AC Terminator Application Configuration 
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Final Channel Assignments 


The only task remaining before we have ee sites | 
our task of assigning channel numbers and physical. 


wire and component locations is to assign these : 


channels on the iCS 920 digital termination panel. 
Since we have already determined that we will uti- 


lize‘ports A and B, this becomes a simple matter, | 
requiring only an arbitrary assignment of lamp. 
locations using these port bits. The assignments 


made for one oven can be seen in Figure 22. The 
entire ladder diagram of the system can now be 


completed along with port assignments for all sig- ~ 
nals used. The completed diagram can be found in | 


Appendix B. Note how the port assignments have 
been shown to the side of the ladder element repre- 
senting that interface device. 


The method used to define a port assignments 
needs to be clarified since it may not be apparent 


why a channel of port.A was given the address of 


E80. To begin, we have already indicated that each 
port consisted of eight channels or bits. We will 


number these bits from 0 to 7. Since it is possible to - 


have many input/output devices connected to the 
computer, the possibility exists of having multiple 
devices which incorporate internally ports A, B, 
and C. The computer has been designed to support 


‘project configuration worksheets. 


first channel of port.A would be defined as having © 
an address of E80; the second channel of port B 
would be E91, and so forth. 2 2 


ut. SELECTING THE COMPUTER BOARDS 


To this point we have delayed the selection of the. 


boards which will be required to provide the com- 
puterized control system. The Intel OEM Micro- 
computer Systems Configuration Guide has been 
designed to simplify the task of selecting the re-' 
quired system. Our first task is to enter all known. 
information describing our desired system into the. 
These work-- 
sheets can then be used to actually select a board 
configuration which meets our particular require-_ 
ments. The effort required to accomplish the entry 
of data is reduced to a minimum through the use of © 


predefined digital and analog configuration work- 


_ up to 256 of these ports so we have numbered them ~ 


using the hexidecimal numbering system. The pos- 
sible port numbers can then range from 00 to FF. It 
will be found that a common characteristic of most 
single board computers is the use of assigning the 


port addresses of E8, E9, and EA to the on-board 


8255 parallel peripheral interface. Therefore, the 
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Figure 22. Digits! Panel Application Configuration 
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sheets. Our requirement of having a total of 24 
parallel data lines, consisting of a mix of high and 
low level interfaces, can be met by the 24-bit 
AC/DC combination. Our assignments of re- 


quirements for the terminator panels can be made 
and is shown in Figure 23. It can clearly be seen 


from the worksheets, that our required interface - 


with the computer digital data will consist of one 


24-bit wide connector (had we not used port C 
assignments, the use of 16-bit wide connectors - 
would have sufficed). This means that our selected 
single board computer or I/O expansion board) 
must provide at least one edge connector having 24 
I/O bits on it.’ 
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DIGITAL CONFIGURATION WORKSHEET 
| PROJECT 


This worksheet will provide the required digital interface configuration 
data which is required to complete the Project Configuration Worksheet. 


Enter Number of Channels 


Enter # of Discrete AC Outputs (115-230 VAC) oo... 00. cccccccccccececeeececeeee Mh (A) 
Enter # of Discrete AC Inputs (115-230 VAC) ....... ccc. cece cc ceceveeeceeeeeeee se, 4 (B) 
Enter # of Discrete DC Outputs (Current > 300 MA)................... eeecah ten ted _O (Cc) 
Enter # of Discrete DC Outputs (Current < 300 MA)...................0000222... MQ (D) 
Enter-#of Discrete DC Inputs: 2.6330). oxy lead alete bd daa eos CAE eas baa wh edness oO. (E) 
Compute the Number of iCS 920™ and iCS 930™ Termination Panels 
First compute the number of Parallel 1/O ports (8-bits each port) required 
on your iSBC™ board. Round all computations up to the nearest whole 
integer unless instructed otherwise! 
Compute # of iCS 930 Interface Output Ports ((A+C)/8) ...... 0... eee I (F) 
Compute # of iCS 930 Interface Input Ports (B/8)...... 0.0. cece cece cece ce eeeeuees L(G) 
Compute # of iCS 930 Termination Panels ((F+G)/2) 0.0.0... cc cece ccc eeceeceeues _ | (H) 
Compute # of iCS 920 Interface Output Ports (D/8) ...... 00 ee eee 2 (J) 
Compute # of iCS 920 Interface Input Ports (E/8)....... 0.0 cee cee nee O (K) 
Compute # of iCS 920 Termination Panels ((J+K)/3) ...... 0.0.00 ccccvcccccesees al ee 
Optimization of Digital 1/O Port Usage for Minimum I/O Configuration 
Compute # of iCS 930 Output “Overflow Channels” DO NOT ROUND OFF) 
(REC)/B decnccuoneratbinia cribs icoiel¢tonsatonnss QUOTIENT 2uisenmtnanc O_ (mM) 
| (Overflow Channels) REMAINDER ...........-. —4 (Nn) 
Compute # of ICS 930 Input Overflow Channels (DO NOT ROUND OFF) 
(BB ii Racrs see ceueec cera cdiacseuiniantomet. at. Bi cues QUOTIENT ..........0000. O_ (P) 
REMAINDER ............. 4 (rR) 
Compute # of iCS 920 Output Overflow Channels (DO NOT ROUND OFF) 
(DY) eee ea a PEL aor ear ee GUO TIENT oe ocs4'ck cee, 2  s) 
REMAINDER ............. _O (T) 
Compute # of iCS 920 Input Overflow Channels (DO NOT ROUND OFF) 
(EB). nat eet ncrecaiah 8 titrate S oes d cuneate Vo Maciel ae none s QUOWHENT. savzus.cwaacvacns _O _ (V) 
REMAINDER ............. _O__(W) 
Compute 8-Bit Input Ports Required (P+V) 2.0.0... .. 0. ccc cece cece eee ences seria =O. (x) 
Compute 8-Bit Output Ports Required (M+S).............0000 eee A Meh votes > sinh teeas p(y) 
Compute 4-Bit Output Ports Required ((N+T)/4) (ROUND UP) ................00. | (2) 
Compute 4-Bit Input Ports Required ((R+W)/4) (ROUND UP) .................05. De (AA) 
Compute 8-Bit Port C Requirements ((Z+AA)/2) (ROUND UP) ................0.. (BB) 
Total 1/O Parallel Ports Required (X+Y+BB)......... 0.0... c cece cece eens oe. (CC) 
Total # of 24 Channel Parallel |1/O iSBC Board Edge Connectors 
(CC/3) (ROUND UP TO:INTEGER): coon rises aww beads eedes s Abeba baw eeds _ | (DD) . 
Compute Power Requirements for the Termination Boards 
(DO NOT ROUND OFF) 

- Compute +5V for iCS 920 Board Outputs (.061*D) ...... cc cece cee eeeeeeeeeeeeees 410 (EE) 
Compute +5V for iCS 920 Board Inputs (.023%E) .... 0... cece cece cece eee ee ees __© (FF) 
Compute +5V for iCS 930 Board Outputs ((.020x(A+C)) ... 0... cece eee eee .... OBO (GG) 
Compute: +5V tor (CS 930 Board lnputs(012* B). sass ded SaaS ia wee eek aaa cad : 


Compute iCS 920 Power Requirements (EE+FF)....... 0.0... 0. cc ccc cee eee eee : 
Compute iCS 930 Power Requirements Neer a oeh coo wilussa shige eotre epee yo ene ante . 


Enter the appropriate Gala: into. ihe Project Configuration Worksheet as shown 


below: 


_ SEE INSTAUCTION SHEET PROJECT ‘CONFIGURATION WORKSHEET 
EQUIPMENT distal 


MEMORY SEAL TO PARALLEL INPUT /OUTPUT ANALOG INPUT/OUTPUT 
oon POWER REQUIREMENT 
ACQUIRE MENTS PROOUCT AAM fleur ~__ Serial Paris Parallel Lines com foes cr a OWE REQUIREMENTS 
eile _ (Bytes) ny : AS23920 N = our 
:s =e — i 
= * € (D) 
ees <9) 
_ 4 ‘5 4 4 
i 
' i : i, : 
= ao Sa a. —-+ + 
’ 
iz, 2 wares os ee 
INTEL t ‘a : ' 
SOLUTION | 


Figure 23. Digital Configuration Worksheet 
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The required power requirements of the termina- 


tion panels can be calculated using the data pro- 
vided in the digital configuration worksheet. The 
information regarding the necessary connectors 
and the power requirements should then be 


transferred to the. ‘Project configuration worksheet ~ 


(Figure 24). 


Figure 24. 


A similar technique is used to configure the analog | 


signals using the standard analog configuration 


worksheet as shown in Figure 25. It can be seen — 


that our application will require a single cable con- 
nection to a differential input edge connector of an 
analog input board. The power requirements can 
be calculated from the current requirements to 
drive the thermistors and the sensing resistors. The 
data is entered into the appropriate columns of the 
configuration tables and then transferred to the 
project conneuration worksheet. 


ANALOG CONFIGURATION WORKSHEET 
PROJECT OVEN CONTROLLER. 


This worksheet will provide the required analog interface configuration 
data which is required to complete the Project Configuration Worksheet. 


Enter Number of Channels : 


Enter # of Single Ended High Level Analog Channels .............0.cecceeeeseeeees {A) 
Enter # of Differential High Level Analog Channels ............ ccc cee ee cece ea eeees (B) 
Enter # of Differential Low Level Analog Channels ............... ccc c cece ener eens O(c) 
Enter # of Analog Output Voltage Channels .............. ccc cece cece erence ee ceees OQ. (dD) 


Enter # of Analog Output Current Channels ........... WT ihaediaduaghobe wate’ iyoienan dhe _O_ (&) 


Compute the Number of ISBC™ Board Edge Connectors = - 


Unless otherwise noted, round all computations to the next largest integer! 


Compute # of High Level Single Ended Analog eg ats (ANB) ss ives see ke ne oe —o ({F) 
Compute # of High Level Differential Connectors (B/8) .......... 0. ccc cece eee ee _1t (6) 
Compute # of Low Level Differential Connectors (C/8)..........00 ee cceveeesaueece O(n) 
Compute # of Analog Intertace pps Corinectors (FAGHA) 6 eine cial stile acres are (J) 


Compute the Number of ics- 10 ™ Termination Panels 


Enter Analog Out Connectors (Dv/4+ £/2). Hy lean. Ne a ttia lor éiarefeiesch esau al ease DNURIO are ee _9O {K) 
Enter # of Analog in royal (uray. 1 Risehindee saith aig Vad aba Canoe ea eee Sed a (Lb) 
Enter Larger of (K) or (L).........0. cele eee Becton teres aes heat Materoreecstoceelsccsa Bate gat sere —_f—(m) 


Place the appropriate data into the Project Configuration Worksheet as shown 
below: , Mees : . 


bedstead PROJECT CONFIGURATION WORKSHEET 


HH 22 Be Sa OD Se 
Figure 25. 


The only remaining physical element of our control 


system which we have not defined is the CRT ter- 


minal which will be used for setpoint entry and 
modification. Communications with a terminal re- 
quires that we provide a serial RS232C port in our 
control system. This port requirement is entered 
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“onto the worksheet and the system requirements 
are totaled as shown in Figure 26. 


Figure 26. 


. We must now iioos the Intel iSBC boards which 


will provide a solution to our system requirements. 
This is done by. referencing the summary of key 


-iSBC configuration parameters to find boards 
which provide the necessary characteristics. Our 


first task is to choose a single board computer 


_ which meets as many of our needs as is practical, 


while providing performance characteristics ade- 


quate to our needs. 
Our first requirement for having support for a 


single RS232C serial communications channel can 
be seen to be met by a variety of possible boards. 


Among the possible boards meeting this require- 


ment are: 
iSBC 86/12™ iSBC 80/10A™ — 
SBC 80/20™ iSBC 80/20-4™ 
iSBC 80/30™ 


We must look further before a final choice can be 
made. Again, it can be seen that all candidates also 


meet the: requirement of providing a minimum of 


- one 24-bit wide digital I/O connector. Our decision 


must be based upon parameters which are not 


~ necessarily related to the input or output capabili- 


ties. Even though we have not yet developed our 
software package for our control system, we can 


safely make some assumptions regarding the com- 


pleted software package and thus define additional 
requirements which will enable us to select our 
desired computer board. The software task will be 


considerably. simplified if we write our programs in 


a high level language and if we use available drivers 


- for our input and output where they are available. 


As we will see, the utilization of PL/M and 
RMX/80™ real-time executive and drivers will 
make this programming task much less demanding 
of our time. The trade-off is that these software 
tools take larger amounts of memory than if we 
were to write our entire application program in 
assembly language. Let us make an initial estimate 
that our system will require about 8K of EPROM 
and in the. neighborhood of 2K of RAM. 
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Entering this data on the configuration worksheet 
(Figure 27) enables us to narrow our choice by 
eliminating the iSBC 80/10A since it does not have 
sufficient RAM on board. 


PROJECT CONFIGURATION WORKSHEET 


Figure 27. 


Since our application is not likely to require exten- 
sive math handling capabilities or high speed capa- 
bilities, we probably do not need the power found 
in the iSBC 86/12; so we will remove this product 
from consideration. 


We are now faced with selecting either the iSBC 
80/20 board or the 80/30 board for our processor. 
Each has certain advantages and disadvantages for 
use in Our application. Let’s compare these two 
boards, considering first the iSBC 80/20, then the 
ISBC 80/30. 


iSBC 80/20 board advantages — Slightly lower 
cost, greater number of I/O lines available. 


iSBC 80/30 board advantages — Faster proces- 
sor, dual ported memory, able to utilize UPI 
modules. 


If the system were to operate in a stand-alone en- 
vironment and we could be certain that significant 
expansion would not take place, we would prob- 
ably choose the iSBC 80/20 computer for our ap- 
plication. If we consider that the system might 
become a part of a much larger system by future 
expansions and additions, we should remember 
that the use of the UPI modules on the iSBC 80/30 
computer provides considerable power through 
multiprocessing capabilities. The dual ported 
memory can also provide us with the ability to use 
more sophisticated inter-board communication 
protocol should the need arise. For the purposes of 
this application note, we will assume the system is 
being designed for expansion and we will select the 
ISBC 80/30 computer. 


A good design practice is to provide an extra mar- 
gin of available memory in the hardware design. 
Our anticipated RAM memory will use about 2K 
bytes. The computer will provide us with 4K bytes 
so we have a considerable margin. This is not true 
when we look at the amount of EPROM available 
on the board. Our 8K requirement is identical to 
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the amount of memory available to us on the 
board. We should consider the use of an expansion 
EPROM board or the prospect of having to spend 
a considerable amount of time reworking our pro- 
gram to get it to fit if we find that we have exceeded 
our estimates. We will select the option of adding a 
memory expansion board (it can be deleted if we 
find that our software requirements are less than 
estimated). 


The computer selection and the memory expansion 
board data can now be entered onto the configura- 
tion worksheet as shown in Figure 28. If needed, 
the addition of the memory expansion board will 
allow our EPROM requirements to grow up to 16K 
bytes. 


PROJECT CONFIGURATION WORKSHEET 


‘ME STRUCTION SuetT 


EQUIPMENT PARAMETERS: 


Figure 28. 


The only requirement which we have not met is to 
assign a board to handle the analog input needs of 
our temperature sensing circuit. The analog voltage 
can be calculated and will be found to lie in the 
neighborhood of 4.6 volts at room temperature. 
This value will increase toward 5 volts as the 
temperature of the oven increases. Since we have 
no requirement for any analog output capabilities, 
we will choose the Intel® iSBC 711™ Analog Input 
Board to sense the voltage level. This board can be 
configured to handle a 5-volt full scale input and 
will provide a resolution of 12 bits. (If an oven re- 
quiring a wide range of temperatures and greater 
resolution were required, we would have to recon- 
figure our temperature sensor to provide a wider 
voltage spread over Operating temperatures. For | 
purposes of simplicity and clarity we will assume 
that our temperature resolution is adequate.) 


The configuration worksheet can be filled in to 
reflect the selection of the analog converter and the 
total power requirements for the system can be 
computed as has been done in Figure 29. We now 
need to select a chassis and power supply in order 
to complete the application hardware design phase. 


The Industrial Chassis 


Before the boards can be operated doeettier to oe m1 
a control system, a means of allowing communica- 
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SEE INSTRUCTION SHEET 


EQUIPMENT PARAMETERS: | 


PROJECT CONFIGURATION WORKSHEET 


ANALOG INPUT/OUTPUT 


Analog conus 


MEMORY SERIAL 1/0 PARALLEL INPUT/OUTPUT 
. Grol ENENTS . PRODUCT fa |EP}ROM Sertal Ports Parallel Lines. oe 
(Bytes) (Bytes) try - [ crszaec | iN | OuT | i6 | 24 


POWER REQUIREMENTS “COST 
no [ si [tow] 0 | wt in| or[ sv [| -iw | ov rev ftlat—«doty dy — J Oty 


INTEL 
SOLUTION 


SLOT #3 


SLOT #4 


SLOT #5 


SLOT #6 
L 


SLOT #7 


SLOT #8 
Ns. 


(" 
SLOT #9 


SLOT #10 


SLOT #11 


SLOT #12): 
A ‘ 


ROM/EPROM 


‘| 1/0 DRIVERS 
TERMINATION 


USER SUPP 
HARDWARE 


( SUBTOTAL | 


NOTE 

O!- Differential Input 
SI-Single ended Input 
10-Current Output 
V0-Vottage Output 


Figure 29. 


tion between the boards and of distributing power 
among the boards must be found. This require- 
ment is met by specifying a chassis into which the 
boards will be mounted. The Intel® iCS 80™ In- 
dustrial Chassis provides an environment for oper- 
ating the boards which is specifically designed to 
operate in an industrial area. 


The chassis has been designed to facilitate mount- 
ing into either a standard 19-inch RETMA cabinet 
or it may be rear-panel mounted into an enclosure 
such as may be found in applications requiring the 
use of aNEMA electrical enclosure. The card chas- 
sis has been mounted in such a manner as to hold 
the single board computers and expansion modules 
vertically, facilitating maximum cooling of the 
boards. Fans are provided to aid the normal con- 
vection cooling process. Card racks may be in- 
stalled into the iCS 80 chassis to expand the card 
support capability to a maximum of 12 card slots in 
groups of four. Either an iSBC 635 or 640 power 
supply can be mounted into the industrial chassis 


to provide power up to 4 or poaigs peg. | 


respectively. 


Abe] 


POWER SUPPLY 


Our application design requires the installation of a 
three board solution, so we will choose the iCS 80 
chassis with one iSBC 635™ power supply. We will 
choose.to mount our control system in a standard 
NEMA 12 enclosure to protect the unit from the 
industrial environment. We should refer to the iCS 
80 Industrial System Site Planning and Installation 
Guide (manual order number 9800798) for com- 
plete details for selecting appropriate enclosures 
and. iistavarion instructions. . 


The +5 volt power needed to support the various 
termination panels and to supply a reference volt- 
age for the thermistors is available from a barrier 
strip located on the lower front of the iCS 80 
chassis (Figure 30). Our wiring can be routed to 
this barrier strip for those circuits requiring either 
5-volt DC or the system logic common. A fuse 
holder is provided and a fuse should be installed 
for system protection. We will install a 2-amp fuse 
into the holder (our maximum power requirement 
for external circuitry should me 1.22 amps accord- 

ing to Figure 26). | 
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CUT JUMPER TO ENABLE FUSE 


Figure 30. Industrial Chassis DC Power Strip 


The remaining terms required in our ladder dia- 
gram (Appendix B) consist of a high voltage 
neutral and a source of switched high voltage 
power for the heater lamps. Both of these terms are 
available from the iCS 80 industrial chassis. It is 
desirable to utilize the same switched power for 
both the computer system and our external signals, 
so that we can provide protection to operators 
when one portion of the system is shut down. A 
common source will insure that all portions of the 
system are inactivated if repair is being done. The 
iCS 80 chassis incorporates a heavy duty industrial 
key-lock switch for its power switching. The out- 
puts of this switch are available to the user at a ter- 
minal barrier strip located on a fold-out panel on 
the rear of the chassis assembly (refer to Figure 31). 


We can see that our neutral wire should be con- 


nected to terminal 5 (filtered AC low) and the wire 
for the AC high, wire #10 on the ladder diagram, 
should be connected to terminal 9. This will pro- 
vide us with a switched, fused, and filtered power 
source for Our external wiring. 


HASSIS GND 


Q : 


[eaten|ralea| afealenlealenlea|ante| 


FILTERED 


| AC LOW 


As we will be installing the chassis into a NEMA 
enclosure, we will not want to use a standard power 
cord since this would involve the additional ex- 
pense of installing a duplex outlet in the cabinet. 
The power wiring can be installed directly onto the 
power barrier strip by placing the AC hot wire on 
barrier number 1, the neutral wire onto barrier 
number 4, and the ground onto barrier number 3. 


The hardware implementation of the system can 
now be considered to be complete. Before the sys- 
tem can function as a control for the oven temper- 
atures, we must define the relationships between 
the various pieces of the oven system and we must 
also define the operator interface with the CRT ter- 
minal. Thus, we begin the software phase of our 
design. 


IV. DETERMINATION OF SOFTWARE 
APPROACH 


The task of providing the relationships between the 
various system components falls into the category 
of writing the software. Before we actually begin to 
develop this software, we will define certain guide- 
lines which can be used to organize and simplify 
the task. 


Let us consider the general environment under 
which our programs will operate. We find that we 
have essentially two choices in this area. First, we 
can consider the entire process as a sequential set of 
predefined operations in which we must perform 
each operation before moving to the next until 
finally we complete the sequence and begin again. 
(This is analogous to using a single stepper switch 
to design our control system.) Since each oven 1s 1n- 
dependent of the others, we can not afford to use 


FILTERED, 

FUSED, & © 
SWITCHED 
AC HIGH 


iCS-80 AC POWER PICKUPS 
» (115 VAC CONFIGURATION) 


Figure 31. Industrial Chassis AC Power Strip 
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this approach since we could get tied up waiting for 


something to happen in a particular oven and 
would have to ignore the other ovens. The designer 


familiar with relay design will probably be think- 


ing, at this point, that we should use a separate . 
sequential Operation for each oven or device to be 


controlled. Indeed, this is exactly what we can do 
with our software by using what is known as a real- 
time executive. This tool will allocate the com- 


puter’s resources in such a manner as to provide us. 


with the capability of having independent software 
programs or tasks operating at what appears to be 
the same time. We will make our first assumption 
that our software will be written using such a tool 
and we will specify that we will operate under 
Intel’s RMX/80 Real-Time Multi-Tasking Execu- 
tive. We will discuss more detail of this software 
tool as we develop our programs. 


Next, we must consider the language which we will 
use. to actually define our required operation. We 
have many alternatives from which to choose. Let 
us look at several of the alternatives in some detail. 


Assembler 


Assembler language is probably the most basic tool 
with which we can program a computer. It is con- 
sidered to be the most efficient user of program 
memory and processor time. These features are 
made possible because each assembler instruction 
line is converted directly into a corresponding 
machine instruction. From a programming stand- 
point, assembler language is the most difficult to 
use since any task must be defined by subdividing 
that task into a multitude of smaller. operations 
compatible with the available instructions of the 
computer. To use this language, we must be famil- 
lar with the architecture of each computer with 
which we desire to operate. The use of the language 
is somewhat simplified through the use of an Intel 
supplied assembler which converts the assembler 
code into machine instructions and provides list- 
ings of the operations which have been entered. A 
complete description of the Intel 8080/8085 As- 


sembler Language is available in the 8080/8085 


Assembly Language Programming Manual (man- 
ual order number 9800301B). 


The user should consider this programming tool 
when his application requires the minimum 


amount of memory (such as might be required for. 


very large volume designs where memory cost is a 
factor) or where a highly time dependent routine 


must be defined. Our oven application does not fall 
into either of these categories, so we will choose 


not to use this language in our instance. 


PL/M 


Intel’s PL/M language offers an efficient, struc- 
tured, high level systems programming language. 
Before proceeding, let us be clear on the benefits of 
using a high level language. First, the use of high 
level languages results in reduced development time 
and cost. High level languages provide the ability 
to program in a natural algorithmic language. In 
addition, they eliminate the need to manage regis- 
ter usage or to allocate memory. Second, high level 
languages provide improved product reliability 
because programs tend to be written in structured 
formats and result in a minimum of extraneous 
branches which might cause testing problems. 
Finally, their use produces programs which are bet- 
ter documented and are easier to maintain. 


On the other hand, high level languages do not op- 
timize the code segments as well as can be done by 
an experienced assembly language programmer. As 
a result, most compilers (routines which convert 
the high level languages into machine executable 
code) use more program storage than those written 
by the assembly language programmer. Different 
languages and compilers require different amounts 
of memory for the same task. 


PL/M-80 is probably one of the most efficient high 
level languages for use on microcomputers. It has 
been determined that PL/M-80 users can expect to 
use between 1.1 to slightly more than 2 times as 
much program memory as would be used for the 
same task written in assembly language. For this 
reason, we must place the use of this language high 
upon our list of possible languages in this applica- 
tion. 


A glance at the PL/M-80 Programming Manual 


~. (manual order number 98-268B) indicates that the 


language is highly structured and seems to lend 
itself very well to handle logical type operations. It 


seems to have the greatest weakness in its math 
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handling capabilities in that it does not support 
negative numbers 
assume that the oven application can be handled 
entirely with positive integer numbers so this 
limitation will not unduly hamper our use of this 
language. We will keep these features in mind when 
making a final decision. 
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or fractions. It is reasonable to ~ 


FORTRAN 


Intel’s FORTRAN-80 provides the full subset of 
ANSI FORTRAN 77. In many cases FORTRAN- 
80 has features that exceed the specifications for 
both the subset and the full versions of FORTRAN 
77. Most of the power of this language lies in its 
ability to easily handle complex mathematical ex- 
pressions. Obviously, it does not have any limita- 
tions regarding fractions or sign of the numbers in- 
volved. It should be used when the application re- 
quires the use of mathematical computations. The 
power of the language, however, means that the 
use of the language will take a heavy toll of mem- 
ory allocation. A complete description of the FOR- 
TRAN version supported by Intel and its use on the 
iSBC computers can be found in the FORTRAN- 
80 Programming Manual (order number 9800481A) 
and in the /SJS-IJ FORTRAN-80 Compiler Opera- 
tor’s Manual (order number 9800480). 


It is unlikely that the magnitude of mathematical 
routines required to control the temperature of our 
ovens will be complex enough to justify the use of 
FORTRAN. Keep in mind that, if such a situation 
were encountered, it is feasible to use a combina- 
tion of programming languages to create our final 
module. 


BASIC 


Certaintly the most well known high level program- 
ming language today is BASIC. It offers a quick 
way Of applying the computational capabilities of 
the computer to a wide range of applications. The 
Intel RMX/80 BASIC-80 is an interpreter designed 
to operate with Intel’s single board computers and 
contains extended disk handling capabilities. As an 
interpreter, it differs from other high level Jan- 
guages in that it results in a relatively slower oper- 
ating solution to an application. It is also not possi- 
ble to use BASIC to generate multiple independent 
tasks which can compete for computer resources. 


For these reasons, we cannot consider the use of 
BASIC for a solution to our application. — 


Final Selection of Language 


From the above discussion, it seems clear that our 
choice for the application being demonstrated is to 
use PL/M-80 as our programming language. 


With this in mind, we can begin the task of actually 
generating the code which will complte our applica- 
tion and provide an operating control system. 
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V. DEFINING SOFTWARE TASKS 


The software implementation can begin as soon as 
we have broken our control functions into inde- 
pendent ‘‘tasks’’. We can then handle each task 
separately as though it were the only thing which 
had to'be done by the control system. In the event 
that we find that one of our tasks must communi- 
cate with or be interlocked with another, we will 
handle this need through the use of ‘‘exchanges’’. 
The ‘‘exchange’’ can be thought of as a mailbox in- 
to which messages are deposited and picked up by 
the various tasks. These messages convey the neces- 
sary information between the otherwise independ- 
ent programs. When all tasks have been coded, we 
will combine them using the facilities of RMX/80. 


Our oven application can be broken down into 
three functional areas or tasks. These are: 


1. The Control Task which will be used to actually 
sense the oven temperature and to provide the 
required responses to the heaters and the indi- 
cator lamps. 


. The CRT Update Task will be used to provide a 
‘*snapshot’”’ of the system operations to.a per- 
son viewing the CRT terminal. 


. The Parameter Update Task will be used to ex- 
amine and update the oven setpoints and toler- 
ances. 


The choice of these three tasks has been essentially 
arbitrary in nature. Certainly, other choices and 
groupings of functions could easily have been 
made. We will use these choices for our example 
and will proceed with our development accord- 
ingly. 

We have two other supporting tasks which must be 
included in our system. Fortunately, these tasks are 
predefined and fully supported within RMX/80’s 
libraries; thus we need not write these functions. 
The two supporting tasks are: 


4. A Terminal Handler Task to support the actual 
interface to the CRT terminal. It provides echo 
of input characters and signals when data is 
ready to be read. It will output messages to the 
terminal and signal when all characters re- 
quested have been sent. 


. An Analog I/O Driver Task to request and han- 
dle the handshaking which is required to 
communicate with the analog input board. It 

will signal us when data has been input and is 
available for use by Our user written tasks. 
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We can proceed with the implementation of éach 
of our three tasks which we have defined. The first. 


step with each will.be to develop a flowchart which 
shows the required operations to implement that 
task. This flowchart will show any intertask com- 
munications or exchanges that may be required 
with other tasks. The flowchart can then be coded 
using the facilities provided by our programming 
language. 


Oven Control Task 


The sequence of operations required to perform 


the control task can be defined using the flowchart 
shown in Figure 32. Let us examine the required 
steps in more detail. 


An arbitrary décision has been made to only sam- 
ple and control the ovens once each second. This 
will allow some time for the system to respond once 
a heater output has been set. The first step in our 
control task is to wait for one second to elapse. 


Our next subtask should be to read the status of the 
various oven control switches on the operator’s 
control panel. This item could wait until a later 
time, but there is no harm in handling it at this 
time. 


Next, we see a block indicating the input of data 
regarding the current oven temperatures. This oven 
temperature data will certainly be used by the task 
handling the snapshot display on the CRT so we 
‘must give some consideration to the validity of the 
data. While we are in the process of getting the 
data and converting it to engineering units (next 
step), there will be periods during which the stored 
temperature data does not reflect the actual oven 
temperature. An example might be when we are ac- 
tually moving the 16 bits of the temperature since 
we can only move data 8 bits at a time. During this 
period, we would not want another task to use the 


data and since each task is going to operate inde- 


pendent of others, we must provide some type of 


lockout of the data while we are operating on the > 


temperatures (an alternative would be to have each 
task get its own temperature from the A/D con- 
verter and convert it to engineering units, but this 
would seem to waste memory and computer time). 
We can provide this. lockout by creating an ex- 
change to communicate with other tasks. If we 
make a message available in this exchange when the 
data is valid:and cause no messages to be available 
when the data is nonvalid, we can effectively lock 
out tasks from using the data when it is in the pro- 
cess of being updated. This is done by requiring 
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those tasks to test for the presence of a message at 
the exchange before they get the temperature data. 
If no message is present, they must wait until one is 
placed into the exchange before proceeding. Just 
before we update the temperatures we will fetch the _ 
message from the exchange, leaving it empty while 
we work on the data. later we will again restore the 
message when the update is complete. 


CONTROL 
TASK s 


WAIT FOR ONE 
SECOND | 


READ CONTROL 
PANEL | 
SWITCHES 


' DATA. 

LOCKOUT 

TEMPERATURES EXCHANGE 
MSG 


~ CONVERT TO 
ENGINEERING 


m 
1 bn | 


3 TIMES 


AVERAGE 


COMPUTE 
710,730 


z 
oO 


Oat 


< 
m 
n 


OPERATIONS 


DO 3 MORE TIMES 


‘CAUTION’ 
OPERATIONS 


2 
+ 
12) 
ry 


SHUT ALL 
OFF 3 


ALARMS 


‘HEATER’ 
OPERATIONS |. 


_ OUTPUT 
DIGITAL 
DATA | 


Figure 32. Control Task Flowchart 
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The number obtained from the analog converter 
provides us with a value which is proportional to 
the temperature of the oven. Our next step is to 
convert this number into engineering units. Unfor- 
tunately, the voltage and temperature are not 


related in a linear fashion since the thermistor is a. 


nonlinear device. We will have to develop a tech- 
nique to obtain a corrected value. For the purposes 
of this application note and in an attempt to keep 
the application as simple as possible, we have 
chosen to utilize a single table look-up to perform 
this conversion. Alternatives might have been to 
utilize FORTRAN routines to mathematically per- 
form the conversion or to have separate tables for 
each oven. Once the conversion has been made, we 
must return a message to the data lockout exchange 
to allow other tasks access to. the data. 


Because we must deal with four ovens, the opera- 


tions related to each individual oven must be per- 
formed four times, once for each. This is easily 
handled as we will see, since PL/M is a block struc- 
tured language. Our flowchart need only remind us 
that the operations need be done four times. 


The next step has been defined as performing some 
digital filtering of the temperature by averaging the 
current temperature with the temperature of one 
second ago. This filtered value will be used to per- 
form subsequent computations and to make future 
decisions. | 


We have defined earlier in our definition of the 
control algorithm that we would use a derivative 
control. We have chosen to project the tempera- 


ture ahead for a period of 10 and 30 seconds. We 


must calculate the rate of change and the 
temperatures in 10 and 30 seconds so that this data 
will be available when needed. 7 


Now that the calculations have been made to dee 


mine numeric values required for the decision mak-. 


ing process, we must begin the process of determin- 
ing the status of each indicator and oven heater. A 


test will be made of the oven run switch and if it is 


found to be turned off, we will turn off all indi- 


cators and the oven heater associated with that. 


oven. If the switch is found to be turned on, we will 
set the status of the ‘‘in tolerance’, ‘‘caution”’ 


and ‘‘alarm’’ indicators according to our oven con- 


trol algorithm. The oven heater will be turned on 
or off according to the projected temperature in 30 
seconds. | 


Rather than output the fanidual< oven indicator 
and heater data four times (once for each oven), we 


will perform the computations associated with 
making the decisicn four times (this saves code 
since we can use the same program steps with only 
pointers being exchanged). At the end of this time, 
a single operation will output the data to all ovens 
and indicators at the same time. Outputting to a 
computer port will actually cause the device to turn 
on or off according to eee the output bit isa 
one or zero. 


We will then return to the beginning of our task to 
wait until another second elapses before we again 
perform the indicated functions. 


Control Task Source Coding — The coding of our 
tasks is a straightforward procedure once we have 
prepared a flowchart. Since we are using PL/M-80 
and RMX/80, the coding sequence for a task will 
be as follows: 


1. Define any variables or structures which will be 
used in the module. This involves providing in- 
formation defining variables as being either an 8 
or 16-bit variable and declaring if that variable 
is to be a part of the task being coded or is to be 
found in some other task. If any arrays or struc- 
tures are to be used, they must also be defined. 
Finally, if any program locations are to be used, 
they must be declared. 


2. The task must be initialized. That is to say that 
any assumptions which will be made as to initial 
data values in subsequent instructions must be 
initially forced to this initial value. 


3. The actual task must be coded to match the 
operations called out in the flowchart. | 


We will look at some examples of this coding pro- 
cess using the control task flowchart. The complete 
listing of this module and all modules actually used 
to provide the oven control system can be found in 
Appendix C. *,, °4 


At first glance, it would seem that the listing is ex- 
tremely complex, but as we will see it is made up of 
straightforward pieces. The listing is made up of 
three parts as we have mentioned above when de- 
fining the steps required to generate a program. 
The first part (line numbers 1 through 50) is used to 
define parameters, variables, and external ele- 
ments. The general types of elements making up 
this portion fall into typical categories. The first 
general category consists of DECLARE state- 
ments, Examples of typical lines will help explain 
their meanings (when actually developing the pro- 
gram, this first section was created piecemeal by 
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making an entry when it was found that.a need for 
that term existed as the execution code in sections: 


two and three were written)... 


Examples of the “declare”’ 
below. For example, on: ‘line I we find: 


“IL 1 Declare (n,k) byte; 


This means that the variables “en? and HK? g are be. 
ing defined as terms which represent numbers or 


data which is one byte or 8 bits wide. The ‘‘11”’ is 


the program line number, and the. a indicates 


that we are in the first level of nesting. 


We can also see the use of the “literal”? expressions 


such as used in line 4. The expression: 
4 1 DECLARE FALSE LITERALLY ‘00H’; 


means that we are creating a new instruction called 
‘false’? and that its meaning is to be interpreted by 


the compiler a as being equivalent to the value of 
zero. 


Rather than dwell. on the iesineatiok, let us move 
on. to the coding process which was used to. gener- 
ate the actual: program. Keep in mind that the use 
of. PL/M- 80 requires that. all terms used be de- 
clared i in the program module. Refer to the PL/M- 
80 Programming Manual (order number 9800268B) 
for a full description of the PL/M language. 


Program Initialization — The initialization portion 
of ithe program can be found,on lines 51 through 59 
of the control task program listing. This section is 
used to initialize data and to provide known entry 
conditions before we enter the. repetitive program 
loop. This code is only executed when the system is 
reset or when the power is turned on. The control 


- Statement are shown 


task requires two types of initializations; one to in-- 
itialize the computer’s. output port-and'the other to. 
set up the A/D converter.. The requirements for’ 


each can be found in the RMX/80 User’s Guide 


and the iSBC 80/30 Single Board Computer Hara- 


ware Reference Manual (order number 9800611A).. 
Actual instruction examples are given in..these. 


manuals for the initialization operations, a 


ee Bolly 2 — The program which h aétvally pro- : 


vides the control operations can be found on lines 


60 through 126 of the program listing for the con- 


trol task. It has been divided into sections which 


correspond directly to the ‘flowchart | that? was. 


prepared earlier. Most - instructions in PL/M-80 
language follow closely the English structure which 


describes what is being done. The exceptions gener- 


ally follow definite predefined formats. The for- 


mat: such as-used on line 61: to wait for one second 
to‘elapse is an example of one such exception. Any: 
time we desire to wait fora et time pened, we. 
use an instruction of the form: ‘3 


MSGS$PTR = -RQWAIT (: DUMMYSEXCH, TIME DELAY); 


Whatever time delay we wish to use is ‘expressed i in 
increments of 50. msec time periods. Our example 
requires. a time delay of.one second 50 we will use 
the delay. notation of 1. 0/0. 050= 20 time units (this 
command is actually calling upon the RMX/ 80 ex- 
ecutive to handle the delay).” 


The oven enable switch data we been defined a us 

to be routed by the hardware.to the.computer port 

‘SR A’’ which converts to.a decimal number, 234. If. 
we define an internal memory location for this.data_ 
and call it BLOCKO, then we can get the oven 

switch data by using an input. statement. Since the. 
data sense is inverted through the hardware, we can 

provide meaningful internal data if the signal i 1s re- 
inverted as it is loaded. into memory. The instruc- 

tion on line 62 of the control task listing performs 

this. task. | 


We are now y ready to get the analog, rr fon the 
A/D converter. Our flowchart shows that we must 
lock out the other tasks from access to the tempera- 
ture data during this time period, so we must first 
remove the enable message from the exchange in 
which it is stored. Messages are removed from an 
exchange by using an instruction of the form: 


"STORAGE = RQWAIT (EXCHANGE NAME 0) 


Line 63 of the program. listing means that we will 
get a message from our storage exchange which j aS 
called “Temp$lockout$exch’’ and store it in.a 
memory, storage area called ‘‘Lockout’’. Now, no 
other task can get a message. from. this exchange 
since it is empty, so it is permissible to operate on 
the temperature data. (Note how similar this com- 
mand is to the one used. to wait fora delay. Indeed, 
this ‘is the same request ‘for RMX/80, ‘but it Te. 
quests a time delay of zero, )- 


During the initialization, we built a message defin- 
ing the characteristics of the analog signals and of 
the analog conversion board which we are. using.. 

Remember that we have indicated that the task of 
getting this data from the board is provided | to us by 
one of RMX/80’s predefined drivers. All that ‘is 
necessary at this time is to inform that driver of our 
desire to get data, then wait until it has done its job 
and the data is available for us. The actual com- 
munication between ‘ our ‘applications ‘task and’ the 
analog driver ‘is done using the idea of an exchange 


similar to that we have used to lockout the data. 
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We will send a message to the analog driver telling 
it what we want it to do, then we will wait until it 
sends a message back to one of our exchanges tell- 
ing us that it is done. The format for sending a 
message to an exchange always follows the form: 


CALL RQSEND (EXCHANGE NAME, MESSAGE NAME); 


Line 64 of the listing shows that we have requested 
the input of the analog data since we have sent our 
message, Convert, to the analog driver’s exchange 
which is called RQAIEX. We will wait until the 
Operation is complete by using the line of code 
shown on the listing line 65. This is the same opera- 
tion type that we used to get our message back pro- 
viding a lockout earlier. The program will wait un- 
til a message is available before continuing. 


The data must now be converted into engineering 
units. We earlier indicated that we would use a 
table lookup to perform the linearization, so we 
have included this table as a part of our program at 
line 50. The offset into the table corresponding to 
Our temperature must be determined so that the 
correct value can be stored. Because we have four 
ovens, we will perform the operation four times 
with the data each time corresponding to the ap- 
propriate oven. These operations can be followed 
on lines 77 through 81 of the listing. 


Lines 67 through 76 are used to establish an offset 
to be applied to the analog temperature data when 
the system is running. This program is only de- 
signed to be used during the start-up operations 
and is activated when a message containing a cali- 
bration request and current temperature is sent to 
its exchange. | 


The temperature lockout must be removed to 
enable other tasks to use this data. This is done on 
line 82 by sending the message back to the ex- 
change used for intertask lockout communications. 


The remainder of the program follows the flow- 
chart and the operations can be followed using a 
flowchart and the listing. Each element of the flow- 
chart corresponds to a block of code on the listing. 


CRT Update Task Development 


Earlier, we stated that the CRT update task would 
be used to allow the operator to view a ‘‘snapshot’’ 
of the four ovens. Let us turn our attention to 
developing the software which is required to ac- 
complish this. We can begin by defining the ele- 
ments which we feel should be displayed, then 
defining the format to actually be used with the 
CRT terminal. 


Obviously, we need to provide the current tempera- 
ture of each oven on our display screen. If we dis- 
play the actual temperature, it seems reasonable to 
assume that we should also show the setpoint so 
that a determination can be made as to how well 
the system is performing. The control algorithm 
has been defined to use an allowable range to deter- 
mine system outputs, so it would seen wise to also 
show this parameter. Finally, we should inform the 
viewer of the status of the oven so that he will real- 
ize that the reason an oven temperature is low is 
because the oven is off rather than an oven mal- 
function, Other items could be added if desired by 
the system designer, depending upon the total SyS- 
tem requirements or the characteristics of the 
users. 


We can now prepare a drawing of the CRT display 
to generate a layout of our desired characters and 
to generate an aesthetic display for viewing during 
operation. This drawing can be found in Figure 33. 


Several techniques are available to output the re- 
quired displays to the terminal. A decision must be 
made as to the frequency of screen updates; will we 
constantly refresh the data or do it only at certain 
intervals of time? If the terminal has the ability to 
disable the cursor, it makes sense to update data 
continuously. If the cursor cannot be disabled, its 
movement tends to be distracting, so the updates 
should be kept to a minimum. The terminal used 
for the application note did not have a disable 
feature, so we will make the decision to only up- 
date the screen once each second. | 


OVEN STATUS DISPLAY 
OVEN-1 OVEN-2 OVEN-3 OVEN-4 
TEMPERATURE XXX.X XXX.X XXX.X XXX.X DEGREES 
SETPOINT XXX.X XXX.X XXX.X XXX.X DEGREES 


TOLERANCE XXX.X- 


XXX.X XXX.X XXX.X DEGREES 


STATUS XXXXXXX  XXXXXXX XXXXXXX XXXXXXX 


TYPE ESCAPE TO ADJUST SETPOINTS. 


ee 


Figure 33. CRT Status Display Layout 


The decision to delay updates leads us to make 
another decision regarding the screen updates. If 
we only update a line which has data which has 
changed since the last update, the cursor move- 
ments will be kept at a minimum since it is unlikely 
that all parameters will ever change each second. 
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A flowchart can now be prepared showing the steps 


required to implement the CRT update task. This 


flowchart is shown in Figure 34. The coding of the. 
program to support this task can be found in Ap- 

pendix C. The development is identical with that 

which we described in the sections regarding the 

control task. Again, the software is divided into 

three parts, the declaration statements from lines 1 

to 81, the initialization on lines 82 to 87, and the 

actual task code on lines 88 to 207. 


(. CRT UPDATE 


WAIT FOR 1 SEC 
AND FOR 
REQUEST 


UPDATE | 
HEADING 
IF NEW 


UPDATE 
TEMPERATURE 

IF CHANGED 
OR NEW 


UPDATE 
SETPOINTS 
IF CHANGED 
OR NEW 


UPDATE 
TOLERANCE |. 
iF CHANGED 
OR NEW 


DISPLAY 
ACTIVE 
EXCH 


REQUEST 
UPDATE 


UPDATE 
STATUS 
IF CHANGED 
OR NEW 


ACTIVATE 
PARAMETER 
TASK 


Figure 34. CRT Status Flowchart | 


A technique to exit from the’ ‘CRT update mode 
and to get into a mode which will allow modifica- 
tion of the parameters has been introduced into the 
program and the display format. This is in the 
form of a message on the botton of the screen re- 
questing the entry of an escape character to adjust 
setpoints. The software has been written in such a 


Ks 


manner as to-test for a character inut from the key- 
board ‘and ‘if one-is found: corresponding’ to: that: 
character, the update-task will allow the parameter’ 
update task to take control of the terminal ciunes 
190 to 204 of the uSHnE), 7 : 


Parameter Update Task 


The parameter update task j is used to eee alow . 
the modification of the setpoints and the tolerances: 
associated with each oven. A second use of the task 

is to provide.a tool for establishing the zero offset 

associated with each analog channel so that an off- 

set into the temperature linearization table can be. 
computed by the control task. . 


Figure 35 shows the flowchart which eceribes the 
steps required to perform these operations. When. 
the task has been completed, we will return to the 
CRT mbes task. : 


“PARAMETER 
UPDATE 
TASK 


GET OVEN 
NUMBER 


GET | 
TOLERANCE 


SEND 
CALIBRATE 
__ MESSAGE | 


DISPLAY 


Figure 35. Parameter Update Flowchart 
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The program code for this task can be found in Ap- 
pendix C and again follows the formats which we 
have discussed earlier. No attempt will be made in 
this document to provide a narrative of the listing 
since it follows the flowchart in development. 


Support Programs 


Three subprograms (procedures) have been written 
which provide functions which are common to the 
three tasks. This has been done to minimize repeat- 
ing code segments thus saving as much memory as 
possible. These three subprograms support: 


1. Conversion of a decimal string from the termi- 
nal into a binary number. This program is called 
ASC$2$BINARY and can be found in Appen- 
dix C, 

. Storage for common variables used by more 
than one task. These variables could easily have 
been included in other tasks but a purely arbi- 
trary decision was made to include them in a 
separate module. 


. Conversion of binary numbers into a decimal 
string suitable for output to the terminal. This 
program is called DEC$REP and 1s found in 
Appendix C. 


We now have completed the coding of the software 
to support our oven application. We must finish by 
combining all the software together to form a 
single loadable module. 
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VI. FINAL IMPLEMENTATION 


When all code was linked and loaded to form an 
executable program module, it was found that the 
system required 9,041 bytes of EPROM and 1,735 
bytes of RAM. These values fall within our hard- 
ware capabilities and will rquire that we program 
and insert nine EPROMs into the EPROM expan- 
sion card. 


The system can now be tested and installed to con- 
trol the ovens of our application. The actual system 
described in this application note has been con- 
structed and tested. It has been found to control 
the oven temperatures of four ovens and performs 
as we anticipated when we developed our control 
strategy earlier in this application note. 


VII. CONCLUSION 


We have shown how Intel’s single board com- 
puters, industrial chassis, termination panels, and 
software can be configured to provide a solution to 
a typical control application. We have seen how the 
development of a solution to a control problem can 
proceed along a predetermined and logical path. 
Truly, the utilization of the microprocessors can 
lead to optimum and cost effective solutions to 
control applications. 
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APPENDIX A 
SELECTED DATA SHEETS 
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mechanical data 


The package 


TYPES TIL3, TILN9 
OPTO-COUPLERS 


BULLETIN NO. OL-S 7312032, NOVEMBER 1973 


Gallium Arsenide Diode Infrared Source Optically Coupled 


to a Silicon N-P-N Darlington-Connected Phototransistor 


High Direct-Current Transfer Ratic ... 300% Minimum at 10 mA 
Base Lead Provided for Conventional Transistor Biasing 
High-Voltage Electrical Isolation . . . 1500-Volt Rating 

Plastic Dual-In-Line Package 


Typical Applications Include Remote Terminal Isolation, 
SCR and Triac Triggers, Mechanical Relays, and 
Pulse Transformers 


consists of a gallium arsenide infrared-emitting diode and an n-p-n silicon darlington-connected 


phototransistor mounted on a 6-lead frame encapsulated within an electrically nonconductive plastic compound. The 
case will withstand soldering temperature with no deformation and device performance characteristics remain stable 
when operated in high humidity conditions. Unit weight is approximately 0.52 grams. 


—~ SEATING PLANE ----- - 


6000 NOTES: 
a, Leads are within 0.005 radius of true position 


(TP) at the gauge plane with maximum materia! 
alas condition and unit installed, 
. All dimensions are in inches unless otherwise 


O@®® noted, 


. Pin 1 Identified by index dot. 


eee SS . Terminal connections: 
ore ee i . 1. Anode ; Infrared-emitting 
0125 MIN cebu | ' Seuacee nm t2e* Cathode : diode 
the Rt | . 3. No internal connection 
28. H 
ee, ua die. eine 
. Collector 
. Base (For TI1L119, make 
no external connection) 


Phototransistor 


absolute maximum ratings at 25°C free-air temperature (unless otherwise noted) 


Input-to-Output Voltage 2. 2. ww ee ee ee ew ELE KV 
Collector-Base Voltage (TIL113) 2. 2. 0. 2 2. ww ee ee ee ee ee ee.) 680V 
Collector-Emitter Voltage (See Note 1) 2 2 2. 1 ww eee BON 
Emitter-Collector Voltage: 3-2 % Sosey aes we te for i a oe a he a Gl ie Gk EE me Ok ae 7V 
Emitter-Base Voltage (TIL113). 0 2 0... ee ee TN 
Input-Diode Reverse Voltage . . . oe ee » » 3M 
Input-Diode Continuous Forward Corrent at (er belo) 25° C Pree: Air Tomperstire (See Note 2) . . . . 100mMA 
Continuous Power Dissipation at (or below) 25°C Free-Air Temperature: 

Infrared-Emitting Diode (See Note 3)... . 2... ee ee ee ee ee ee 150 mW 

Phototransistor (See Note4) . .. . . LAB ood tee Ae a ae ae 4 is te SOW. 

Total (Infrared-Emitting Diode plus Bhotateansieter, See Note 5) fb Oa ee ike a ea de ae , OO IW 
Storage Temperature Range... Phe fo BOGS Hs eke ate ee we ty, Be 150-C 
Lead Temperature 1/16 Inch from Gass foi 10 Second: oe we eo at BAG Yond fe ie ae Soe ee ee ee GOEG 

. This value applies when the base-emitter diode is open-circuited. 


NOTES: 


. Derate linearly to 100°C free-air temperature at the rate of 1.33 mA/°C., 


. Derate linearly to 100°C free-air temperature at the rate of 2 mW/°C. 
. Derate linearly to 100°C free-air temperature at the rate of 3.33 mw/°C. 


1 
2 
3. Derate linearly to 100°C free-air temperature at the rate of 2 mw/°c, 
4 
5 


TEXAS INSTRUM ENTS 


ORPORATED 
POST OFFICE BOX 5012 e¢ DALLAS, TEXAS 75222 


Reprinted with permission from Texas Instruments, March, 1979. All rights reserved. 
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TYPES TIL13, TIL19 
OPTO-COUPLERS 


electrical characteristics at 25°C free-air temperature 


TIL113 TIL119 
PARAMETER TEST CONDITIONSTt 
MIN TYP MAX |MIN TYP MAX 


Collector-Base 


V Ic = 10 nA, le = 0, lp =O 
(BRICBO Breakdown Voltage C . E 5 


re Collector-Emitter , ian | 0 | 0 30 30 
= mA, = i = 
(BR)CEO Breakdown Voltage C i 
Emitter-B 
ViBRJEBO “ le = 10 uA Ic =0, Ip =0 i 
Breakdown Voltage 


NIT 


Cc 
< < 


E ' 
Emitter-Collector 
FE = 10LA, 
On-State Vce=t1V, Ig = 0, lp = 10mA 30 100 


V | 
(BRIECO Breakdown Voltage 
Clon) Collector Current Voce = 2V, ip = 10mA See 
Off-State 
IC(off) : VcE = 10V, Ip = 9, Ip =0 
Collector Current 


Transistor Static 
Forward Current ViGE = Ty; Ic =10mMA, If =0 15,000 
Transfer Ratio 


3 


7 
30 160 


Input Diode Static 

Ve lp =10mA 1.5 1.5 
Forward Voltage 

VCE (sat) ; Vv 
Input-to-Output 

nO ‘ is Vin-out =£1.5kV, See Note 6 1911 1011 ) 
Internal Resistance 
Input-to-Output 

om Renae eae Vice O, f=1MHz, See Note 6 Pte 1 1.31] pF 
Capacitance 


NOTE 6: These parameters are measured between both input-diode leads shorted together and al] the phototransistor leads shorted together. 


T References to the base are not applicable to the T!L119. 


switching characteristics at 25°C free-air temperature 


, ‘TIL113 TIL119 
TEST CONDITIONS 
MIN TYP MAX |MIN TYP MAX 
ty Rise Time Vec = 15V, IC(on) = 125 mA, 
f Fall Time R_ = 1002, See Figure 1 
: 
f 


PARAMETER 


: 
PARAMETER MEASUREMENT INFORMATION 
[ | 472 Adjust amplitude of input Pulse for: 
ip ie INPUT IC(on) = 125 mA (TIL113) 
a IC(on) = 2.5 mA (TI1L119). 
tA . 
aes, | 


n 


50 
50 


= 
is =e Zz 
+ 


OUTPUT 
R_ = 1002 OUTPUT 


a 


TEST CIRCUIT = | VOLTAGE WAVEFORMS 


NOTES: a. The input waveform is.supplied by a generator with the following characteristics: Zoy; = 50 2, tp < 15 ns, duty cycle > 1%, 
tw = 100 us. 
b. The output waveform is monitored on an oscilloscope with the following characteristics: t; < 12 ns, Rin 2 1 MSL, Cin < 20 pF. 


FIGURE 1—SWITCHING TIMES 


TEXAS INSTRUMENTS 


INCORPORATED 
POST OFFICE BOX 5012 e DALLAS, TEXAS 75222 
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TYPES TILN3, TILNS 
OPTO- COUPLERS 


TYPICAL CHARACTERISTICS 
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OFF-STATE COLLECTOR CURRENT 
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IC (off) —Off State Collector Current—pA 


Ta—Free-Air Temperature—°C 


FIGURE 5 


NOTE-.7: Puise operation of input diode is required for operation.beyond limits shown by dotted line... . 
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TYPES TIL3, TIL19 
OPTO-COUPLERS 


TYPICAL CHARACTERISTICS 


TIL113 | 
RELATIVE COLLECTOR-EMITTER 


SATURATION 
NS 
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VCE (sat) -Collector-Emitter Saturation Voltage 
Relative to Value at Ta = 25°C 
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CONDUCTION CHARACTERISTICS 
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FIGURE 8 


NOTE 8: This parameter was measured using pulse techniques. ty, = 1 ms, duty cycle < 2%. 
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OPTO 22 


I/O Module Detail | 
Electrical Specifications 


ee 


AC INPUT MODEL MODEL MODEL MODEL MODEL MODEL DC INPUT MODEL MODEL MODEL 


MODULES IAC5 1AC15 IAC24.-—s«IAC5-A_—si IAC 15-A_—« 1AC24-A MODULES | IDC5 IDC15 IDC24 
AC INPUT LINE 95 to i 180 to INPUT LINE 10-32 VDC 
VOLTAGE - 130 VAC = 280 VAC » VOLTAGE | — 
INPUT CURRENT | | 
AT RATED LINE 10 ma SS ge INPUT CURRENT 32 maat 32V ———______-» 
ISOLATION ISOLATION INPUT: _. 
INPUT TO OUTPUT. 2200 Volt RMS ——AA@ $a > TO OUTRIT 2500 Volt RMS —————_» 
INPUT ALLOWED |... | CAPACITANCE 8 Pr . 
FORNO OUTPUT °°. g INPUT TO OUTPUT Z 
a | ; INPUT ALLOWED 
TURN ON TIME 20 Millisecond Maximum —— > -FOR NO OUTPUT 2ma eee ee ae 
TURN OFF TIME 20 Millisecond Maximum —-————————_—___________»> TURN ON TIME 5 Millisecond Max —————____> 
OUTPUT TRANST. : re 
BREAKDOWN BO Wols DC sa ne TURN OFF TIME — 5 Millisecond Max ee 
7 OUTPUT TRANST. | 

OUTPUT CURRENT 25 na Fee BREAKDOWN 30 Volts DO ————_—_»> 
OUTPUT LEAKAGE | 
30VDC, NO. INPUT 100 Microamp Maximum ——AA > OUTPUT CURRENT 25 Ne eee 
OUTPUT VOLTAGE | OUTPUT LEAKAGE 
DROP .4 Volts at 25 ma Load a Sn and 30 VDC NO INPUT 100 Microamps Ne Fee 
LOGIC SUPPLY 45to ' 12to 20to 4.5to 12 to 20 to OUTPUT VOLTAGE 4 ot at 05 ma 
VOLTAGE DC 6V 18V 30 V 6V 18V 30 V DROP ar a 
LOGIC SUPPLY LOGIC SUPPLY 4.5 to 12 to 20 to 
CURRENT 12ma 15 ma 18 ma 12ma 15 ma 18 ma VOLTAGE 6V 18V 30V 
Baan a ee a Fe ah ee ag Se ee Bae ae ee LOGIC SUPPLY 12 
AC OUTPUT MODEL MODEL MODEL MODEL MODEL MODEL CURRENT ma  15ma 18ma 
MODULES OAC5 OAC15 OAC24 OAC5-A OAC15-A OAC24-A 

12 to 24 to . Se atair oS MeAE  RIGRED MNGREIO 
LINE VOLTAGE Sen nenE NI ORE sta ee DC OUTPUT MODEL MODEL MODEL 

140 VAC 280 VAC MODULES ODC5 ODC15 oDc24 
CURRENT RATING 3 AmpsO | LOAD VOLTAGE —60V 

| RATING DC 

1-CYCLE SURGE 55 Amps Peak ———————_-——____________> ce ras CURRENT 3 amps 
SIGNAL INPUT 220 1K 2.2K 220 1K 2.2K OFF STATE 
RESISTANCE Ohm Ohm Ohm Ohm Ohm = Ohm LEAKAGE ON 
SIGNAL PICKUP 3V 9V 18V oh ae 9V 18V ISOLATION 
VOLTS DC BV Ald* 16VAld* 32VAld* 8VAld* 16V Ald’ 32V Ald? INPUT TO OUTPUT 2909 V RMS > 
SIGNAL DROPOUT \o4 | SIGNAL PICK UP: 3V QV 18V 
VOLTS DC ; | VOLTAGE - 8VAId* =18V Ald? 28V Ald? 
PEAK REPETITIVE SIGNAL DROP 

DOO oe ces Pe ee eC 
VOLTAGE 500 Volts AGT VOLTAGE 1Volt 
MAXIMUM 1.6V = om : SIGNAL INPUT 220 1K 2.2K 
CONTACT DROP RESISTANCE Ohm Ohm Ohm 
OFF STATE 5 ma RMS 
LEAKAGE a - - - 1 SECOND SURGE 5 Amps —————_ 
MINIMUM 20 ma : 
LOAD CURRENT 0 SSS TURN ON TIME 500 Microsecond ——————_» 
ISOLATION ‘ 
CAPACITANCE 8 PF | | * Allowed 
INPUT TO OUTPUT ) | , @Derate .033 Amps per degree C from 20° C 
STATIC fae 
DV/DT 200 Volts/Microsecond Min ———_—___________> 
COMMUTATING Built in snubber (will commutate 
DV/DT .5 power factor loads) 
*Allowed = 


5842 Research Drive, Huntington Beach, California 92649 (714) 892-3313 
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High Voltage DC Output Modules 


DC OUTPUT 
MODULES 

LOAD VOLTAGE 
RATING 


OUTPUT CURRENT 


RATING 


OFF STATE 
LEAKAGE 


ISOLATION 
INPUT TO OUTPUT 


SIGNAL PICK UP 
VOLTAGE 


SIGNAL DROP 
OUT VOLTAGE 


SIGNAL INPUT 
RESISTANCE 


1 SECOND SURGE 
TURN ON TIME 


TURN OFF TIME 


“Allowed 


MODEL MODEL MODEL 
ODC5-A ODC15-A ODC24-A 
200V 

DC 


2500 V RMS ————> 


3V 9V 18V 
8V Ald? 18V Ald* 28V Ald? 


DBO —— SS 


220 1K 2.2K 
Ohm Ohm Ohm 


5 Amps ————___—>- 


500 Microsecond —————> 


2.5 Millisecond ————_—_______> 


Fast Switching DC Input Modules 


DC INPUT 
MODULES 
INPUT LINE 
VOLTAGE 


MODEL MODEL MODEL 
1DC5-B 1DC15-B IDC 24-B 


4-16 VDC 


INPUT CURRENT 


14ma at 5V -—-—__---—__-— 


ISOLATION INPUT 
TO OUTPUT 


2500 Volt RMS ———--———— > 


CAPACITANCE 
INPUT TO OUTPUT 


8 Pf __________—_—_» 


INPUT ALLOWED 
FOR NO OUTPUT 


TURN ON TIME 


TURN OFF TIME 


OUT TRANSISTOR 
BREAKDOWN 


OUTPUT CURRENT 


1 Volt ————_—__—___—_—_—_——_—_——__> 


50 Microsecond Max ———__—> 


100 Microsecond Max ———————_—_> 


30 Volts DOC ——_____________—_> 


25 ma ——— 


OUTPUT LEAKAGE 
30 VDC NO INPUT 


~ 100 Microamps Max ee etereilaee 4 


OUTPUT VOLTAGE 

EE EDR RRR _ocetl 
DROP A Volt at 25 ma 
LOGIC SUPPLY 4.5to 12 to 20 to 
VOLTAGE BV 18V 30V 
LOGIC SUPPLY 
CURRENT 1 SS ee 
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APPENDIX C 


PROGRAM SOURCE LISTINGS 


TRIAL 


CONTROL SERIES IN CONTRCL 


STITLE (‘CONTROL TASK') 
JRA ERR KIER IKI RR ARID RARE RRR TKI RD IR RTI R AR IR 


* This task hane@les the control 


* four oven chambers. 
JIG GIORGIO TOI TOTO SIO ITO RTO III 


CONTROLS TASKO MODULE: 


Do; 


DECLARE FXCHANGESPESCRIPTOR LITERALLY 


MESSAGESHEAN ADDRESS, 

MESSAGRS'TAIL ADDRESS, 

TASKSHEAD ADDRESS, 

TASKSTAIL ADDRESS, 

EXCHANGESLINK ADDRESS)'; 
DECLARE TRUE LITERALLY (CORFU; 
DECLARE FALSE LITERALLY '@@H'; 
POOLEAN LITERALLY 'BYYE'; 
DECLARE FOREVER LITERALLY ‘WHILE 1°; 
DECLARE MSGSHDR LITERALLY ! 


DECLARE 


LINK ADDRESS, 


LENGTH ADDRESS, 


TYPE BY 


TE, 


HOMESEX ADDRESS, 

RESPSEX ANDRESS ' ; 
DECLARE MSGEDESCRIPTOR LITERALLY ‘STRUCTURE ( 
MSGSHDR, 
REMAINDER (1) 


/* AIMSG,. 


DECLARE 


/* ATTYP. 


Declere 
Declare 
Declérsé 
Declare 
Declare 
Reclare 
Declare 
Declare 
Declare 
Declare 
Declare 
Declare 


ATMSG 


ELT - 


ISQS 
ee 
ATRAN 

(n,k 
(MEGS PT 


BYTE) ' 


oe 'OTRUCTURE ( 
MSGSHDR, | 
STATUS ADDRESS, 
BASESPTR ADDRESS, 
CHANNELSGAIN ADDRESS, 
ARRAYSPTR ADDRESS, 
CCUNT ADDRESS, — 
ACTUALSCOUNT ADDRESS) ' 


and monitoring of 


"STRUCTURE 


ANALOG INPUT MESSAGE TYPES my 
DECLARE ee LITERALLY ‘232° 


f 
LITERALLY. '31', 
LITERALLY '32', 
ees pee ae 
aon oun ‘) address; 


NCE (4) address external; 


TEMP (4) address external; 
SETPOIN'' (4) address ageay neds 
TSAVERAGE (4) address; 


TSLAST eo aa 
TSLASTSAVERAGE (4) address; | 


(4) eddress; 


T$t5(4) eddress; 
TSt1O (4) eddress; 


STATUS ( 


4) byte external; 


Declare CRTSMISPLAYSLOCK (5) address 


3.39. 


externel,; 


APPLICATIONS 


& 
* 


ELT - ANALOG INPUT REQUEST MESSAGE FORMAT */ 


e (BLOCK@,RLOCK],BLOCK2,BLOCK3) byte external; 
TOLERA 


AFN-01931A 


Declare TEMPSCALTBRATE (5) address external; 
Beclare DUMMYSEXCH(S) address external; ot 
Declare TEMPSLCCKQUTSFXCH(S) address external; 


] 

od 
26 1 
27 ] Declare RGAIEX(5) address external; 
Ze 1 Declare ASNSEXCH(S) address external; 
29 ] Declare CONSTANTS LGCKOUTSEXCH(5) address externel; 
38 } Declare CRISSTATUSSEXCH(5) ederess external; 
37 #1 Declare ALARMSMSG structure (MSGSHDR) ; 
22 iL Declare CONVERT 2i1S$msa; 

/* Tnis term is used to convey initial temperatures * / 

32 1 Declare CAL*TEMP besed MSGEPTR structure ( 


MSGSHDR, 
| CAL address ); 
34 | RQWAIT: | ; 
Procecure (EXCH,MESSAGE) address ‘external; 


35 . Declare (EXCH,MESSAGE) address; 

34 2 end ROWAIT; 

27 ] ROSEND: | 7 
Procecure (EXCH, MESSAGF) external; 

28 2 Neclers (EXCH,MESSAGE}) ecdress; 

29°? end ROSEND; | | | 

46 E! RQACP1: 


Procedure (EXCH) address external; 


A] a; Reclare EXCH address; 

42 ? end RQACPT; ne 

42 ] Declare OVENSINSTOL(4) byte data .( 
MLlH, ©2H,E4H, @@H ); 

44 . Declare OVENSCAUT ION (4) byte Cate (— 

| | 1Qh, 2FH,4°H,&FtH. }3 | 

4s 1 Declare OVENSDANGER (4) byte Cate ( 
O1lH,@2H,C4H,C28H ); y gat 

a Declare OVENSONSMACK (4) byte date (... 
AlH,G2U, CAH, Ce Ya 7 

47 ] CTeclare OVEN ISHEATER (4) byte data ( 
1@hH, 2GH, APH, S@H ya 

4& ] Declare OVENS ne ') byte jae ( 
LOH, 26H, 4H, SPH 3}; 

£0 1 Declare OFFSET (4) address; 

ae ® HI Declare TAKLE(255) eddress cake 


200,201,206 24 263,204,275, 276,207,288, 2F°, 
QWO 5 218 4-24 Fy 2104 2) By 1S O15 21572) Ts 2185 
2165 206, 927 2224923 224 225 2067 27 Toe 
229,23, 231,232 ,233, 235,226,237, 222,225, 
240,241,202, 244,245,907, 262, 249,256,251, 
PED yg 2g oO yep 2 oy oy POC Re 1 geo 3 ploy 
265,257,268,269, 278,271 ,273,274,276,278, 
DTS QE FAD PE 28S 207 7 OPO eho Ot, 28) 5 
292,295,296, 298,299, 300, 202, 264, 385, 307, 
36%, 369, 210, 212,214, 315, 218, 320,222,224, 
9263204 236 2325 945 57 2 ey 348 5 ha, 
345,348, 250, 282, 254,256, °5P, 260, 3625264, 
364,358, 3704272, 2374 776g: 278, 386,382,385, 
3O2, 796,262,308, 25997, °0F, CeO, 2E8 4207 AIG, 
P12 ES JO18: 020,022, 428 028, 026,433,426, 


,Ig 4 ee AGS —. Ane “@ hm oy ae 
A sabe, AAV, Ad pth 1,454, 087 pla ee a GLAS, 
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NS RO SS AQ NDAD OAD N 


od 


mh DP 


AO UT 


t 


RGR? I MTG OL On LO pCO MOG Eee 
Dire oh yl oy SLO, £27, £27, 821, 5: yy oy 
BSC poo Sy holy Soo g eye ter poly yee ey 
H00, GAS, “10 AIS, 520, 625, iS, 4 5 SAP, 645, 
65%,655,666,655,578,575,686,585,596,595, 
TEP, TGS, TUL) 745) 720) 725,730, 735, 760, 245, 
THC, COB, BRE, CHC, NOC, BRE, Le OLE CEC, ORO, 
PAC COE, CFE, COE, ERE, COE ELE, cee, CEN, BER, 
Eun eaeee ore a ie a 0. 
ACO,CHL, PRE, CHE, FER, EOP 


baad 
=e 


/* TInitializetion of control task */ 
CONTROLS TASK : 
Procecure public; 
Output (235)=814H; 
CONVERT. BASESFE'TR=GF TUE FH; 
CONVERT. LENG TH= oa 
CONVERT... TYPE=A1SCS;. 
ig ee ai 
CONVERT. CHANNELSGAINES; 
CONVERT .ARRAYSPTR=. TEMP; 
CONVERT .COUNT'=4 ; 
Do Forever; 
/* Wait for one second to elapse */ 
MSCEBTREROWAIT (.DUMMYSEXCH, 2¢); 
/* Bring in Geta from switches */ 
BLOCKG=NOY INPUT (224); 
/* Lockout teompereture storage éreas for updete */ 
LOCKOUT=ROWA IT (2.7 EMPSLCC KOUTSEXCH,¢); 
/* Get raw cata from analog converter */ 
Call ROSEND (.RGAIEX,.CONVERT) ; 
MSG SPTR=RQWATT (.ASDSEXCH,®%) ; | 
/* Temperature celibrete procedure */ 
MSGS PTR=ROACPT (.TEMPSCALIBRATE) ; 
Tf MSGSPTR <> &¢ 
then do; 
k=; 
Do while (TABLE (K)<>CALTEMP.CAL AnD 
K< 255) 4 
hR=k+]; 
end; 
To n=@ to 3; 
OFFSET (n) = (TEMP ( n)/is)-k; 
end; 
enc; 
/* Convert cate into engineering units */ 
Do n=@ to 2; | 
if ( (TEMP (n) /16)~ OFFSET (n})>255 
then TEMP (n)=; 
else TEMP (n} =TABLE ( (‘LEMP (n}/1G)-GEESET(n)); 
| enc; i | 
—/* Releéese lockout of temperatures */ 
Cel] ROSEND (.TEMPSLOCKOUTSEXCH, LOCKOUT); 
/* Compute averege tempercture *¥/ | 
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Do n=& to 23; 


» WwW 


oS 


mn 


Aa 


oa mre) 


i. 
ae) 


= LF On 


ming 


TEAVERS AGE (n)=(TSLAST (NP +TEMP (Nn) )/2; 
a Ce temperatures, into the future */ 
“ee TSAVERACE (n) > =P s SLASTSAVERAGE (n) 
Jt hen do; | 
‘WSte (n)= a (T SAVE RAGE (n} _VSLp STSAVE RAGE (n))*5 
-  +TSLASTSAVERAGE(n); |. 
| gree ONS RAGED) ~TSLASTSAVERAGE (n)) *] 7) 
— pee en naron eeu 


end; 
else do; ee a 
StS (n) =TELAST SAVER: AGE (n)- ( (TSLASTSAVERAGE (n) 
~TSAVERAGE(n))*5); 
St1@ (n) =PSLASTSAVERAGE (n)~ ( (1 SLAS PES PVERAGE it) 
=’ SAVERAGE (n)) *1¢ ie 
end; a 


f* Update stored cata a/ ? | 
TELASTSAVERAGE (n) =TSAVERAGE (n); 
TSLAST (n) =TEMP (n); cf - 
/* Test For ective oven */ 
MSCEPTR=RQWAIT (. CONSTANTSLOCKOUTSEXCH, 0); 
L£ (( (BLOCK, AND OVENS ON SMAS K.(n)) <>) 
AND (TEMP(n)<>@)) | 
then cdo; | - 
STATUS (N)=7; | 
RLOCK 2= BLOCK? CR OVENSRUN (n)j; 
/* Test for an intolerance condition */ | 
tf SETPOTNT (n) -TOLERANCE(n). < TEMP(n) AND 
SETPOINT (1) +TOLERANCE (n) > TEMP (n) 
then COp 
~SoTATuUsS (n)=7; a 
~BLOCKI=BLOCK] OR OVENSINSTOL(n) ; 
end; oo” | | 
elsc BLOCKI=BLOCK] AND NOT OVENSINSTOL (n); 
/* Test for @ caution condition */ 
| ne Ee SETPOINT (n) ~{OLFRANCE(n) > TSt5(n) OR | 
— SETPOINT (n) +fOLERANCE (n) < TS$t5(n) 
then cdo; 
STATUS (n) =14; 
| ‘BLOCK1= PLOCK} OR OVENSCAUTION (n) ; 
end 
else BLOCK1=BLOCK] AND NOT OVENSCAUTLON(n); 
/* Test for a@ eenger condition */ : 
If SETPOINT (n)-TOLERANCE(n) > TEMP(n) Ok 
SETPOINT (n)+TOLE RANCE(n) < TEMP (n)} 
then’ do; | 
STATUS (n)=21; 
_ BLOCK2=BLOCK2 UR OVEN SDANGER (n) ; 
Send; | | re 
ee} Se BLOCK?= =FLOCK? AND NOY CVENSDANGER(n); 
/* Randle contro] of heatec elements */ 
Jf SPTPCENT(n) >. StI" (n) 
then BLOCK3=BLOCK? OR OVENSHEATER (n) 
| else ELOCK?=BLOCK23 AND NOT OVENSHEATER (n) ; 
end; © ad | 
else eq aoe 
/* Turn everything Off when operator shuts off oven */ 
| BLOCK] =BLOCK] AND NOY CVENSINSTOL(n);: 
BLOCK1=BLCCK)] AND NCT OVENS CAUTION (n}; 
BLOCK3=RLOCK2 AND NOT OVENSHEATER (n) ; 
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BLOCK2=ELOCK? AND NO'U OVENSDANGER(n}; 


BLOCK2=BLCCK2 AND NOT OVENSRUN(n); 
STATUS (n) =f; 
end; 


Call ROSEND(. CONSTANTS LOCKOUTSEXCH, MS IGSPUR) ; 


enc; 


/* Cutput cata to real world */ 
OUTPUT (2?22)=BLOCK]1; 
OU PUT (233) =ELOCK2; 
OUTPUT (234) =RLOCK?; 

enc; 

end CONTROLSTASK; 

end CONTROLSTASKSMCDULE; 


MODULE INFORMATION: 


CODE AREA SIZE = (GASH 237 4D 
VARTABLE AREA Siar = G@CS4H | CAD 
MAXTMUM S'TACK SIZE = 


CEEGH 6D 
235 LINES READ : 
@ PROGRAM ERROR(S) 


END OF PL/M-&@ COMPTLATION 


SPITLE ('CRT PARAMEWER TASK") 
ee ee 


* This task is used to examine and update the * 
* venperature setpoints anc tolerances for is 
* each of the four ovens. | : 


ePPerecerecerretrscrescerr rrr r rr retritis trey 
UPDATESTASK: | 
Ro; 


SInclude (:F: COMMON. ELT) 

DECLARE TRUE kere ae "GFEFH! 

DECLARE FALSE LITERALLY '(@H'; 

DECLARE BOOLFAN LITERALLY 'BYTE'; . 

DECLARE FCREVER LITERALLY "WHILE 1°; 

ftInclude (:FA:sMSGTYP.ELT) 

DECLARE D&éTASTYPE LITERALLY '¢! 
INTSTYPE LITERALLY '1l', 
MISSEDSINTS TYPE LITERALLY rot, 
TIMESOUTS TYPE LITERALLY '3', 
FSSREQSTYPE LITERALLY .'4', 
UCSREQSTYPE LITERALLY '5', 
FSSNAKSTYPE LITERALLY ‘'6',~ - 
CNTRLSCSTYPE LITERALLY '7', 
READSTYPE LITERALLY '8! | 
CLRSRDETYPE LITERALLY ' 
LASTSRDSTYPE LITERALLY 
ALARMSTYPE LITERALLY '11 
Peek LITERALLY 12's 


' 

aoe 
1G" y 
' 


‘S$Ineclude: (:E@:MSG.ELT) 
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DECLARE MSGSHDR LITERALLY 


LINK ADDRESS, 

LENG''H ADDRESS, 
TYPE 
HOMESEX ADDRE 
RESPSEX ADDRESS' 


DECLARE MS SGSDESCRIPTOR 
MSGS 


BYTE, 


‘HDR, 


ano 


wa gz 


’ 


REMATNDER(1) BYTE) ‘3 


SInclude 
DECLARE THSMEC 


MSGHDR, 


STATUS ADDRESS, 


(:FP:THMSG. ELT) 
LI TEKALLY 


BUFFERSADR ADDRESS, 


COUNT’ 


ADDRESS, 
ACTUAL ADDRES 


S, 


REMAINDER (12@) BYTE)"; 


DECLARE MINSTHSMS SCSLENGTH LITERALLY. 
FA:CHAR. ELT)” 


SI 


/* 


nelude (: 


“LIYERALLY 


SPECIAL ASCII CHARACTERS * / 


DECLARE 


NULL 


CONTROLSC 
_ CONTROLEE | 


BELL 


TAB 


LF 


NT 


KF 

CR 

CONTROLSP 
CONTROLSO 
CONTROLSR 
CONTROLSS 
CONTROLSX 


CONTROLS2 7 


ESC 
CUOTE 
LCA 
LCZ 


RUBOUT | 


SInclude. 
ROSEND: 


PRCCEDURE 
DECLARE 


END RCS END; 


ROW A, } TT: 


PpeceDune 
DECLARE 


LITERALLY 
LITERALLY 


LITERALLY 


res enNae nee 


LITERALLY | 
‘LITERALLY 


LITERALLY 


LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 


LITERALLY 


LITERALLY 


LITERALLY 


"eC ’ 
“Con. 
'A5H" 
'C7H! 


"YO! 


UAH! 


LITERALLY | 


"CBE" 


tgcHt 


LITERALLY > 


LITERALLY 


_LETERALLY. 
LITERALLY. 


LITERALLY 
LITERALLY. 


i EC: SYNCH. EXT) a 


3-44 


'eDH! 
'ient 
‘y1n' 
ee Be» 
(13H! 
"10H! 
"TAR! 
'URH! 


"22h" 
ee 


‘TAH 


‘~~ = =. ene ee en ee ee | 


UF; ” 


(EXCHANGES “PCINTER, 
(EXCHANGE SPOINTER, NESSAGES POINTER) 


AAG 
red 


SPOINTER, DELAY) 
(EXCHANCESPOINTER, DELAY) - 


‘STRUCTURE ( 


STRUCTURE  ( 


a0 


ACESPOINTER) 


EXTERNAL; 


ADDRE 


fim 
Sener ‘2 


ARPDRESS EXTERNAL; 
ADDRESS ; 
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NI 


A ead 


EE eo ee Se Oe ee ee] — MY 


Hoi on dt it 


Hot 


END RQWAIT; 


ROACPT: x 
PROCEDURE (EXCHANGESPCINT&R) AND 
DECLARE EXCHANGES POINTER ADDRE 


SS EXWERNAL; 


e 
¢ 


‘ 


i 
o 


£ 


iN 


END RCACPT; 


ROISND: | 
PROCEDURE (IEDSPTR) EXTERNAL; 
DECLARE IERSPTR ADDRESS; 


END RCISND; ae 
Reclersc TEMPSCALIBRATE(S) ace@ress externs]; 
Declere UPDATESEXCH (5) -a@Cress external; 
Declare CRYSSTATUSSEXCH(S) aceress external; 
Neclere COMPSEXCH(S) aderess uxternel; 
Declare CONSTANTSLCOCKOULTSEXCH(S) aderess externe]; 
Ceclere RQOUTX (5) eceAress axternel; 
Declace ROINPX(5) ¢cddress cxternal; 
Declare WORPRSSEXCH(5) address externel; 
Declare SETPOINT (4) address externel; 
Declare TOLERANCE (4) address external; 
Declare EUFFER? «ddress; | | 
Declare MSGSPTR aeddreass; 

Neclare MSG structure (_ 
MSGSHDPR, 
STATUS address, — 
BUFFERSPTR a@cress, 
COUNT Adress, 
ACTUAL address); . 
Declere CALSTEMP structure ( 
MSGSHDR, 
CAL adcress ); 
Neclare UPDSMSG edéress; | | | 
Declere ENERGIZE hasec UPDEMSG structure ({ 
MSGGHDR, — . 
STATUS eddress, | 
BUFFERSPTR address, 
COUNT address, 
ACTUAL address ); eS. 
Declare ENABLESMSG structure (— 
MSGSHPR ); © SS: - 
Declare BUFFER(SC) byte; 
Declare OVEN byte; -_ 

DECSREP: | = ar 
Procedure (SOURCE, TARGET) externel; 
Declare (SOURCE,TARGET) adecress; — 

end DECSREP; eS | 
ASCS2SBINARY:. | =e 
Procecure (SOURCE, TARGET,S1ZE) byte external; 
Declere (SOURCE,TARGET) address; 
Declare SIZE byte; 
end ASCS2°SBINARY; -_ 

Reclare MSGS1L(2f) byte cata ( 

SC,'E',"ENTER CVEN NUMBER-'); 
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mMuten 
DV OT 


oee 


a ee ee ee 


‘J £9 19 09 


[2d Tad 


1) tad [2d tad 


nd 


Declare MSGS2(2f) byte déta ( © 
CR,LE, | 
'ENTER NEW SETPOINT 
"XXXX.X-' ); 

Dealrere s Sau coat byt B. Ge ibe 
CR,LF, | Gs 
‘ENTER NEW OLERANCE-' 
"XXXX.X-' ); 

Declere CALMSC (12) byte dé ( 
'TEMPERATURE- a. ee 

Declare MSCS4 (G2) pyte Gata ( 
CR, LF, | 


'(STATUS~-(S), PARAMETERS ~ (P) , CALIBRATE r= CCV y 


CR,LF, 
(ENTER REQUESI~" ) 5 
Declere WALT literally | ‘MSCSPTRE 
Declare FOR literally 'ROWALT'; 
Neclare. START literally ‘'CALL'; 
Declare TASK literally "RCSEND'; 
UPDATE: 
Proceecvure public; tte 
/* tAibieli ze task at start- “up time */. 
Do forever; | | 
MSG. RESPSEXS. COMPSEXCH; ft 
f* Weit for request to enter task */ 
UPDSMSG=RQWAIT (.UPDATESEXCH,{); 
/* Get Gesired oven number From operator */ 
— RQOSTSOVEN: a 
MSG. KUFFERSPTR=.MSCS]; 
MSG. TYPE=WRITESTYPE; 
MEG .COCUNT=2F; 
conn tasK C4 RQOUTX, .MSG) ; 
Wedt for (.COMPSEXCH,©); 
ft ... Input new number */ 
MOG. BUFFERS PYR=. BUFFER; 
es COUNT=255; 
SG. TYPE=CLRSRDSTYPE; 
oe task (. ROQINPX,.MSG); 
Weit for (.COMPSEXCH,€); — | 
OVEN= (BUFFFR(@) AND OIE )<1; 
Lf CVEN >3 then aofto ROSTSOVEN,; 
/* Display request ane curvent setpoint */ 
GETSTEMP: | ak. | 
Call move (28,.MSG2,.BUFFER) ; 


el] DECSREP (. BeTyPE; 


MSG. TYPE= WRITESTYPE ; 
MSG.COUNT=28& ; 
Stert task (. eee ar SG), 
Wait for (.COMPSEXCH,§); 
se ee new setpoint oy, 
SG. TYPE=CLRERDETYPE; 
ane rt task (. RQINPX,.MSG); 
Wait FOr Cs COMPSEXCH, 6); 
lt -ASCS2SBINARY (. BUFFER, .BUFFER2, ly=f¢ OR 
then gosto GETSTEMP; | 
If BUFFER2 <> 
then do; | _ ee Pein 
Weit for (.CONSTANTSLOCKOUTSEXCH,(); 
SETPOINT (oven) =BUFFER?; . 


BUFFER2. 


Shart tas ak ( CONSTANT SLOCKGUTSEXCH,MSGESPTR) ; 


346 


> FEL 
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‘Wd 


tA G2 GI Gd Ud 


fad 


& 


&® hA BAA A AA 


mS & 


enc; 


/* Display request and current tolerance */ 
GETSTOL: | 
Call move (29, .MSG$2,.BUFFER); 
Call NDECSREP (. TOLERANCE (oven) ,.BUFFER4 22); 
MSG. TYPE=WRITES'TYPE; 
MSG.COUNT=29; | 
Stert task (.RQOUTX,.MSG); 
Wait for (.COMPSEXCH,(); 
/* ...Input new tolerance */ 
MSC. TYPE=CLRSRDSTYPE; 
Start task (.ROQINPX, MSC); 
wait for (.COMPSEXCH,®&); | 
Tf ASCS2SBINARY(. BUFFER, .BUFFER2, 1)=€6 OR BUFFER2 > 
then gofto GETSTOL; 


If 


BUFFER2 <> @ 


then do; 


end; 


Weit for (.CONSTAWTSLOCKOUTCEXCH, #); 
TOLERANCE (oven) =BUFFER2; 
Start task (. CONSTANTSLOCKCUTSEXCH, MSGSPTR); 


/* Ask operator if he is pinienes 4] 
REQSNEXT: 


MSG. 


TYPR=WRITECTYPE; 


MSG.COUNT=62; : 

MSG.BUIPFERSPTR=.MSGS4; | 

Start task (.~.RQQUTX,.MSG); 

Wait for (.COMPSEXCH,?@); 

/* ..eGet his response */ 

MSG. TYPE=CLRSRDSTYPE; 

MSCG.BUFFERSPTR=.BUFFER; | 

Start task (. RQINPX, .MSG) ; 

Wait for (. ,COMPSEXCH, A); 

If (EUFFER(@) <>'S' AND BUFFER(@) <>'P! 
AND BUFFER(@) <> 'C') | 

then go$to REQSNEX'T; 

IF BUFFER((@)='P! 
then goSto ROSTSOVEN; 

Tf BUFFER (&)='C' 

then do; 


end; 


GETSCAL: 

MSG. TYPE=WRITESTYPE; 

MSG.COUNT=12; 

MSG. BUFFERSPTR=. CALMSG; | 

Stert task (.RQOUTX,.MSG); 

Weit for (.COMPSEXCH,€); 

MSG. TYPE=CLRSRDSTYPE; 

MSG. BUFFERSPTR=.BUFFER; 
Start tesk (.RQINPX,.MSG)j;_ 

Woit for (.COMPSEXCH,¢); 

Tf ASCS2EBINARY(. BUFFER, .BUFFER2 v1) = 
OR BUFFER2?>25¢0 OR BUFEER2<206 

then go$to GETSCAL; 

Sle aplee CAL= -BUFFER2;  — . 
Call ROSEND (.TEMPS SCALIBRATE, «CALSTEMP) 7 


700 
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he NO 


MODULE INFCRMATION: | : 
€3C3H — 


CODE AREA SIZE = — 963D 
VARIABLE AREA SIZE = f@7CH 124D 
MAXIMUM STACK SIZE = S(@4H = 4D 


964 LINES READ 
(F PROGRAM ERROR(S). 
END OF PL/M-&@ COMPILATION 


ENERGIZE.TYPE=106; _ end 
Start task (.CRTSSTATUSSEXCH, UPDSMSG) ; 


enc; 


end UPDATE; | 


end UPDATESTASK; | 


nnnh ut wt nn tt tb tt ttt ton on 


STITLE(*CRT UPDATE TASK") 

TERT ITO BIO IIIT IT RII TIT I TTR IR IIR TICK TRA HE 

* This task is utilizec to upéeete the CRT ter- * 

minal @Cisplay with the current operéeting par- * 

ameters. It wil] be entered upon sytem start- * 

up, upon operator request, or when a problem * 
* 
/ 


* & + 


* exists with any of the activated ovens. 
KK MEK KEKE EK KK KEKE EKEEKRKEEKEKREAREEEKEH REE KERS 


CRISDATASMCDULE: 


Do; 
SINCLUDE (:F@:SYNCH. EXT) 
ROSEND: 


PROCEDURE (EXCHANGESPOINTER, MESSAGESPOINTER) EXTERNAL; 
DECLARE (EXCHANGESPOINTFR,MESSAGESPOINTER) ADDRESS; 


END RCSEND; 
RQWAIT: | a ' 
PROCEDURE (EXCHANGESPOINTER,DELAY) ADDRESS EXTERNAL; 
DECLARE (EXCHANGESPOINTER,DELAY) ADDRESS; 
END ROWALT; 
ROACPT: | | 
PROCEDURE (EXCHANGESPOINTER) ADDRESS EXTERNAL; 
DECLARE EXCHANGES$POINTER ADDRESS; 
END RQACE?; 
ROISND: 
PROCEDURE (IEDSPTR) EXTERNAL; 
DECLARE IED$PTR ADDRESS; 


END RCIEND; | 
SINCLUDE (:F?:MSGTYP.ELT) 


DECLARE PATASTYPE LITERALLY '@',, 
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LD 


V4 
7 


18 
1S 


2¢ 


21 


22 


1 on ee 


| ne 


You tou wm tt Hou ul 


Hook uw ot th tt ott H 


| on 


hor dv tt ued it 


hon Ww at 


tou at 


tu wo nw fob wot 


INTSTYPE LITERALLY '‘'l', 
MISSENSINTSTYPFE LITERALLY 
TIMESOUTSTYPE LITERALLY '3',- 
FSSREOSTYPE LITERALLY '4', 
UCSREOSTYPE LITERALLY 'S', 
FSSNAKSTYPE LITERALLY '6', 
CNTRLSCSTYPE LITERALLY '7', 
READSTYPE LITERALLY '?', 
CLRSRDSTYPE LITERALLY '9', 
LASTSRDSTYPE LITERALLY ‘10 ', | 
ALARMSTYPE LITERALLY ‘'ll', | 
WRITESTYPE LITERALLY ‘'12'; 
SINCLUDFE (:F@:EXCH.ELT) | 
DECLARE EXCHANGESDESCRIPTOR LITERALLY 
MESSAGESHEAD ADDRESS, 
MESSAGESTALL ADDRESS, 
TASKSHEAD ADDRESS, 
TASKSTALIL ADDRESS, a 
EXCHANGESLINK ADDRESS) '; 
SINCLUDF (:F@:COMMON.ELT) 
DECLARE TRUE LITFRALLY '@FFH'; 
DECLARF FALSE LITERALLY '@@H'; 
DECLARE BOOLEAN LITERALLY ‘'BYTE'; 
DECLARE FOREVER LITERALLY 'WHLLE 1"; 
SINCLUDE (:F@:MSG.ELT) | 
DECLARE MSGSHDR LITERALLY ' 
LINK ADDRESS, 
LENGTH ADDRESS, 
TYPE BYTE, 
HOMESEX ADDRESS, 
RESPSEX ADDRESS'; 


DECLARE MSGSDESCRIPTOR LITERALLY 
MSGSHDR, eee 
REMAINDER(1) BYTE)‘; 

SINCLUDE (:F@:CHAR.ELT) 


/* SPECIAL ASCII CHARACTERS */ 


ae aay 


DECLARE . | 
NULL LITERALLY 'C@H', 
CONTROLSC LITERALLY '@2H', 
CONTROLSE LITERALLY '@5H', 
BELL LITERALLY 'f7H', 
TAB LITERALLY '@SH', 
LF LITERALLY '@AH', 
VT LITERALLY ‘¢BH', 
FF LITERALLY '@CH', 
CR LITERALLY '@DH', 
CONTROLS$P LITERALLY '1¢H', 
CONTROLSOQ LITERALLY '11H', 
CONTROLER LITERALLY '1]2H', 
CONTROLSS LITERALLY '13H', 
CONTROLSX LITERALLY '18H', 
CONTROLSZ LITERALLY '1AH', 
ESC LITERALLY ‘1BE', 
QUOTE LITERALLY '22H', 
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"STRUCTURE ( 
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N 
£4) 


m 


NSN ON 
3YV CT 


28 


Zo 


39 


— 


ye 


oe ee 


LITERALLY 


61H" 


LCA ; 

LCZe* . _ LITERALLY '7AH', 

RUBOUT LITERALLY '7FH'; 
SINCLUDE (:F@:THMSG. ELT) 


DECLARE THSMSG LITERALLY 


MSGHDR, | 
STATUS ADDRESS, | 


BUFFERSADR ADDRESS, 


COUNT ADDRESS, 
ACTUAL ADDRESS ,. 


“STRUCTURE ( 


REMAINDER(128) BYTE) '; 


DECLARE MINSTHSMSGSLENGTH LITERALLY | 


Declare HOME literal. 
Declare LISIMAGE (Sf) byte data ( 


Home, Lt ,bE,.Lt bt , Gt, 


UN EMPERATURE 


‘DEGREES C. i 


, 


a] ‘at : 
“y. 'IBH, 48H"; 


Declare - cna. byte Geta (-. 
Home, Lf£,L£,L£, LEY aoe Lf, 


‘SETPOINT 


' ' 

’ 
1 ’ 

’ 
i] ' 

a 


"DEGREES C.' ); 


Declare sea Bic: data ( 
i Home, L€, LE, LE, LF, oe Lt Le, be; Lf, 


 TOLRRANCE 


, 
' ' 

o 
¢ i] 

( 


"DEGREES C.' ); 


Declare L4SIMAGE(75) byte data ( 


Home, L£,L£,LE£, Lt, Lt, 


"STATUS 

OFF ty 
' OFF eee 
' OFE t 

Pe ORE Py 


LE, L£,LE,LE,LE,LE, 


Declare CRTSHDR (168) byte date ( 


1BH,45H,* 


"OVEN Shes DISPLAY", 


Cr, bt Le, 
‘OVEN- a 
"OVEN-? > | ae 


'OVEN-3 | alas 


: OVEN-4 ‘ 
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a 


34 


76 


AG 


Lf, 
"TYPE ESCAPE TO ADJUST SETPOINTS' ); 
Declare BFELLS(4) hyte date ( 
Bell,Bel],Bell],Bell ); 
Declare MESSAGES (35) byte date ( 


pee ae 
¥ OK or 
"CAUTION', 
' ALARM ', 
] Y ye 


Declare DISPLAYSPTR1] (4) adAress date ( 
~WORKSBUFF+23, | 
~WORKSBUFF+26, 
eWORKSKUFF+4°C, 

-WORKSBUFF+52 ); 

Declare DISPLAYSPTR2(4) eddress deta ( 
eWORKSBUFF+25, | | 
»-WORKSBUFF+3@, 

WORKSBUFF+51, 
-WORKSBUFF+64 ); | 

Declare DISPLAYSPTR2(4) address Cata ( 
-WORKSBUFF +27, 

-WORKSBUFFt46, 
WORKSBUFF452, 
~WORKSBUFFH+56 ); 

Declare DISPLAYSPTR4 (4) eddress Cata ( 
~WORKBUFF+3¢, 
»WORKBUFF+43, 
-WORKBUFF+56, 
~WORKBUFF+59 ); 

Reclare MSGSPTR adcress; 2 

Declare MSC basec! MSGSPTR structure ( 
MSGSHDR, | 
COUNT adecress ); | 

Declare STARTER(3) structure ( 
MSGSHDR ); 

Declare READ Structure ( 

MSGSHDR, 

STATUS address, 
BUFFERSPTR adcress, 
COUNT address, 
ACTUAL address );7_ 

Declare DISPLAYSTEMP(4) structure ( 
UPPER address, 

LOWFR eddress ); 

Declure DISPLAYSSET (4) structure ( 
LOWER adcress, 

UPPER eacdress ); 

Declare DISPLAYSTOL(4) structure ( 
LOWER acéeress, 

UPPER address ); 


3-51 


Cra Lf 7 Lif, li, be, Le, Lf, bi, lt, Ll, Le, lr,li, Lt sli, bt, Li,li, bi, be, 
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AA 


45 


46 


-Declere OVENSON (4) byte data (— 


C1H,@2H,@4H,@8H ); 
Declare OVENSCAUTION (4) byte Gata 

TPH, 2CH,4FH,@0H ); | 

Declare CRT structure ( 
MSGSHDR, | a 
STATUS nao ree ss. 
BUFFERSPTR address, 
COUNT adcGress, 
ACTUAL address ); 


(0 


Declare CRITLOCK structure (MSGSHDR); 


Declare CRT sD TSP EAy Shock >) address externé]; 
Declare TEMPSLOCKOUYVSEXCH(5) address 
Declare CONSTANTSLCCKOUTSEXCH (5) | adér 
Declare CRYSEXCH(S) address external; 


external; 
ress external; 


Declare CRTSSTATUSSEXCH(5) address external; 
Declare DUMMYSEXCH(5) address external; 
Reclare READSBUFFERSEXCH(5) address externa 
Declare UPDATESEXCH (5) tate external; 


Reclare ROINPX(S) address external; 


Declare RCOUTX (5) eee external; 
Declare ROWAKE(5) address external; 
Declare ROCLTEX(5) address external; 
Declare RQLGEX(5) address external; 


Declare RQDBUG(5) edcress external; 


Declare ROALRM(®) address externéel; 
Declare TEMP(4) address external; 


Declere DISPSTEMP (2) ecdress; 


Declare Se 4 eee eddress externéel]; 


Declare DISPSSETPNT (4) address; 


Declare TOLERANCE(4) address s external 


Declare DISPSTOL (4) ade@ress; 
Deciare STATUS (4) byte. external; 
Declere DISPSSTAT (4) byte; 


Declare (BLOCK1,BLOCK2) byte external 


Declare WORK SBUFF (178) byte; 
Declere BUFFERSA(7®) byte; 


Declare (CHANGE,n,ALARM,NEW, BLANKER) 


Declare START Titerally call’; 


Declare TASK literally ‘'rqsend'; 

Declare WAIT literally ‘msgSptr=' 

Declare For literally ‘rawait';. 
DECSREP: 


Procedure (SOURCE, TARGET) external 
NReclare (SOURCE,TARGET) address; 


end DECSREP; 


¢ 
: 
byte; 
, 


Ly 
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fad 
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a 
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CRYSDATASTASK: 


Pr 


ocecure pu 


on eee 


/* Initialize system at Start-up time */ 


Start task 
Start task 
STARTER (2). 
Stert task 
CRT.RES PSE 


(. TEMPSLOCKOUTSEXCH, .STARTER (f) ); 

(. CONE STANTELOCKOQUTSEXCH, «STARTER (1) ); 
TYPE=10@; 

(. CRTSSTATUSSEXCH, . STARTER (2}) j 
X=.CRPSEXCH; 


/* Perform mein CRT weit */ 
Do forever; 


/* 


/* 


Walt “f 
Wait £ 


If MSC. 


then A 
else A 
Output he 
L£ (MS 
then ¢ 

Lf 


or (.DUMMYSEXCH, 16); 
or (.CRYSSTATUSSEXCH,4@) ; 
TYPE=255 
LARM=1; 
LARM=¢; 
acing */ 
G.TYPE=1F@ OR MSG.TYPE=255) 
0; 
ALARM=4 7 
then cé)]1 ROSEND(.CRTSDISPLAYSLOC%, .CRTLOCK) ; 


CR. TYPE=*WRITESTYPE; 


CR 


RE 


T.COUNT=157; 


CRI. BUFFERSPTR=.WORKSBUFF; 


AD. TYPF=CLRERDSTYPE; 


READ. COUNT=255; 


RFE 


RE 


EE 


th 
Ca 


AND. RESPSRX=.READSBUFFERSEXCH; 

AD. BUF FERSPTR=.BUFFERA; 

ALARM=6 | | 

en Start task (.RCINPX,.READ); 

ll move (82,.CRTSHDR, -WORKSBUFF); 


Call move (£6,.CRTISHDR+°2, .WORKOBUFF+82) ; 


St 
Wa 


art task (.RQOUTX,.CRT); 
LE: for eCRUSEXCH 0 )> 


NEW=1; 


- end; 
Test for 
CHANGE 
Wait f 
Do n=6@ 
Lf 
th 
enc; 
oy mM 
tart 


change in temperature of any oven */ 


=" s 
or (. TEMPSLOCKOUTSEXC ey; 
bo (3: 


a caine 
en CHANGE=1; 


ove (&,.TEMP,.DISPSTEMP) ; 
task (.TEMPSLOCKOUTSEXCH,MSGSPTR) 


™=e 


/* ee a change exists build. new line */ 
If CHANGE OR NEW | 


/* 


then @€ 
Ce 
Do 


en 
Output ne 


OF. 

1] move (00, .LISIMAGE, .WORKSBUFE) ; 
nef to 3; 

Cal] DECSREP(.DIS SPSTEMP (n) ,DISPLAYSPTRI (n)); 


dG; | 
w temperature line .to CRT */ 
CRT. TYPE =WRITESTYPE; 


CRT. COUNT=87; 
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NaS 
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/* 


eas 


fk 


/* 


Tes 


Start task (.ROQOOUTX,.CRT); 
Weit For (. CRTSEXCH, Ce oe 
end; | 
ae for change in ovens eseanis ay 


Boies 


Wait for ( “CONSTANTS LOCKOUTSEXCH, 


Do. n=@ to 3;. 


Bui 


Cut 


Tes 


ie SETPOINT (n) <>DISPSSETENT (n) 
then CHANGE=1; 
end; | 
Call move (8,.SETPOINT,.DISPSSETPNT) ; 
Start task (.CONSTANTSLOCKOUTSEXCH,MSGSOPTR) ; 
Id new line when a change was detected */ 
Tf CHANGE OR NEW 
then do; | oe 7 
Call move 2 eer MAGE, eV ORKEUEE)Y 
Do n=@ to 2; : 


C1] ne a DYSPSSETPNT(n), DISPLAYSPTR2(n)); 


end; 
put setpoint line */ 
CRi. TYPE=WRITESTYPE; 
CRT.COUNT=8°; 
CRT. BUFFERSPTR=.WCRKBUFF ; 
Start task: (.RCOUTX,.CRT); 
Wait for te CRISEXCH, GY)e. 
ence eo 
t for spange:: in tolerance ine */ 
ae ee C; | 
fait for (. CONSTANT SLOCKOUTSEXCH, O); 


1a is — to 232; 


whe 


Out 


Tf TOLERANCE (a) <oDIs sPETOL (n) 
then CHANGE=1; 

end; be _ 

Call move (8,.TOLERANCE, .PISPSTOL) ; 

Start task (.CONSTANTSLOCKOUTSEXCH,MSGS PTR); 

n change is found, build new line *#/ | 

Tf CHANGE OR ae | 

then do; a s 
Call move ( 
Do n=%@ to 2; 

Call DE 


|, -L2$IMAGE, WORKS BUFE) ; 


G4 
ens REP (. DISPSTOL(n), DISPLAYS ‘PTR 
end; 
put tolerance line */: 
 CRI.TYPE=WRITESTYPE; 
CRT.SCOUNT=91; | | 
Cire. BUFFERSPTR=.WORKBUFE ; 
Stert task (.RQOUTX,.CRY); 
Wait for (.CRTSEXCH,%); | 
end; i 


/* Build status messege */ 


CHANGE=6; 
Wait for (. CONSTANT SLOCKOUTEEXCH, CO); 
Do n=@ to 23: 

Tf STATUS (n} <>DISPSETAT (Nn). 

then CHANGE=}3 ; 
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177 4 end; | | 
Call move (4,.STATUS, .DISPSSTAT) ; 


178 S 
179 2 Start task (.CONSTANTSLOCKOUTSEXCH,MSGSPTR) ; 
/* Output to displey */ 
18A 3 If CHANGE OR NEW 
then co; 
182 4 Call move (75,.L4IMAGE, .WORKSBUFF); 
183 4 Do n= to ?; 
184 5 Call move (7, MESSAGES+DISPSSETAT (n) ,DISPLAYSPTR4 ( 
ee Ee 
185 5 end; 
186 v4 CRT. COUNT=7646; 
187 A Start task (.RQOUTX,.CRT); 
188 Ae Weit for (.CRTSEXCH,®@); 
189 4 end; 
/* test for request to exit this mode */ 
196 3 MSGSPTR=RQOACPT (.READSBUFFERSEXCH) ; 
191 3 If ALARM=f 
then co; 
193 4 If (MSGSPTR <> © end BUFFERA(@) = 1BR) 
then co; | 
195 5 MECSPTRERQWAIT (.CRTSDISPLAYSLOCK, 6); 
196 5 Start task (.UPDATESEXCH,MSGSPTR) ; 
197 5 enc; 
Loe 4 else do; 
199 5 Tf MSGSPTR=(3 
then STARTER (2).TYPE=2¢¢; 
20) 5 else STARTER(2).TYPE=1%8@; 
22 S Start task (.CRTSSTATUSSEXCH, .STARTER(2)); 
242 «5 NEW=@; 
264 5 end; 
205 a end; 
ORG 3 enc; 
207 2 end CRTISDATASTASK; 
208 1 end CRTSDATASMODULE; 


‘aan 


CODE AREA SIZE 


G7 2CH 1824D 


VARTABLE AREA SIZE = @1 89H 3¢°3D 
MAXIMUM STACK SIZE = @(@ (4H 4D 


3Pf& LINES READ 
® PROGRAM ERROR(S) 


END OF PL/M-8@ COMPILATION 
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STITLE(’ASCTI STRING TO FIXED | BTNARY') 

[OIG GIGI IOGIOIGIG CIC HOGIOIGIOIG GIT TOTOR TORTI 
* This program converts an ASCIT string into a fix- * 
* ed point binary number. The fixed Cecimél point #* 


* is determined by the parameter passed in SIZE: * 
RAR RRR RIERA EIR RR ERR EIR IR IRR IERIE IRIE ERE / 


p~ 


ASCS2SBINARYSMODULE: 


AS 


SPSBINARY: 


Do; 

/* SPECIAL ASCII CHARACTERS */ 

DECLARE | | 
NULL LITERALLY ‘GH’, 
CONTROLSC LITERALLY '(3H', 
CONTROLSE LITERALLY '@5H', 
BELL LITERALLY '@7H', 
TAB LITERALLY '#9H', 
LF LITERALLY '@AH', 
VI LITERALLY '¢BH', 
FF LITERALLY 'fCH', 
CR LITERALLY '@DH', 
CONTROLSP LITERALLY ‘'1@H', 
CONTROLSO LITERALLY ‘11H’, 
CONTROLSR LIVERALLY '12H', 
CONTRCLES LITERALLY, '1°?H', 
CONTROLSX LITERALLY '18H', 
CONTROLSZ LITERALLY '1AH', 
ESC LITERALLY 'IBH', 
QUOTE LITERALLY "220", 
LCA LITERALLY. '41H', 
LCZ LITERALLY '7AH', 
RUBOUT LLTERALLY ‘7FH'; 


NON BIN DN 


Procedure (SRCSPTR, TRGTSPTR, SIZE) 
Declare (SRCSPTR,TRGT$PTR) acdress; | 
Declare (SCURCE based SRCSPTR) (83F) byte; 
Declare RESULT besed TRGTSPTR address; 
Declare (N,SIZE,K,DP,DIGITS,VALID) byte; 
Declere POWER (5) adéres S date ( 

0,1,1]@,1@6,1476,1¢6CR ); 
/* Find location of decimal point */ 
N= > 


byte public; 


No while SOURCE (n)<>'.' 
AND SOURCE (n)<>LF; 
n=nt+l1; 


end; 


AND fF QURCE(n)<>CR 


DP=n; 
/* Provide correct number of meres to aie of sseiiel */ 
Do n=? to SIZE; 
SOURCE (DP+n)=SOURCE (DP+n+1); 
TF SOURCE (DP+n)>29H OR SOURCE (DP+4+n) <3FH 
tnen do k=n to SIZE; 
SOURCE (DP+k)='@'; 
end; 
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20 3 end; 
/* Mark end of string */ 
24 2 DIGITS =DP+SIZE; 
/* Test for ell valid cheracters */ 
2 VALID=1; : 
23 2 Do n=f to DIGITS; 
3 If SOURCE (n)>32°H OR SOURCE (n) <3PH 
then VALID=€; 
26 3 end; 
2 2 If DIGITS>s 
then VALID=€; 
/* Convert data to binary and store */ 


29 2 n=; 
3 2 Tf VALID=1 

then do; 
a? 3 RESULT=@; 
33 3 Do while DIGITS > ; 
34 4 RESULT=RESULT ¢ ( ( 

SQURCE(n) AND (FH) * POWER(DIGITS)); 

Bes: 4 n=n+1]; 
35 4 DIGITS=NDIGITS—-1; 
ad, a end; 
ae 3 end; 


/* Return to calling program */ 


29 2 Return VALID; 
4g 2 end ASCS2SBINARY; 
4) ] end ASCS2SBINARYSMODULE; 


MODULE INFORMATION: 


CODE AREA SIZE = #178H 3276D 
VARIABLE AREA SIZE = #PAH TED 
MAXIMUM STACK SIZE = O@N4H 4D 


8 LINES READ 
f PROGRAM ERROR (S) 


END OF PL/M-& COMPILATION 


RE RE PEt A A A RP RSPAS PEE RSA . 
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STITLE ('COMMON VARIABLE STORAGE'). 

SRR RAK IKI IRR IKK RIKER RRR RRR ERE RES RARE EE 

* This mocule conteins those veriahles common to *. 
* multiple tasks in the oven control application. * 

HARKER E KEE KER EE EKREEKEKEER KE RK ERK ERE KERR ERREREEE / 


im 


VARIARLESSTORAGE: 
Do; Bae ee . eg 
2 1 Declare SETPOINT(4) address public; 
3 ] Declare TOLERANCE (4) address public; 
4 ] Declare TEMP(4) address public; — 
5 t Declere STATUS (4) byte public; 
6 ] Declare BLOCKS byte public; 
< ] Declare BLOCK] byte public; 
e ] Declare BLOCK2 byte public; 
e ] Declare BLOCK? byte public; 
lA 1 


end VARTAELESSTORAGE; 


MODULE INFORMATION: 


CROCE an) 


CODE AREA SIZE = 
VARIABLE AREA SIZE = @@2(H 32D 


MAXIMUM STACK SIZE = SPH |. FD 
16 LINES READ | 
( PROGRAM ERROR (S) 


END OF PL/M-8@ COMPILATION 
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DVM GW 


26 


nd 


NM NN NO 


Se) 


NO 


NO ww AQ 


i Go AS 


ae 


m™ WO NAS 


STITLE(*WORD TO ASCII CONVERSICN') 
[BRE IKKE ERE RII KERR RK KI REI I RRR AKER KIER EER ERK IR IK AA 


This routine converts a fixed point wore in 


* 


* 


able number. Zero blanking is 


DECSREP: 
Procedure (SQURCE,TARGE') public 
RNReclere (SCURCE,TARGET) address; 


Neclare ANSWR(S) byte; 


included. 
IK RIK RI RRR RRR IK KR IKK IR KKK RIKER RIK RR ER IKK IK / 
DECSREPSMODULE: 
Do; 


c 


Declare (DISPLAY basece TARGET) (5) 
Declare NUMBER based SQURCE structure ( 


ELEMENT eCdress ); 
Declare N byte; 
Declare CALC(5) address; 

/* Tnitialize */ 

Do n=" to 4; 
ANGWR(n)='@'; 

end; 

CALC (@)=NUMBER. ELEMENT; 

/* Convert: to ASCII */ 

Do n=l to 5; . 
CALC (n) =CALC(n-1)/1@; 
ANSWR (&-n)= (CALC (n-1) mod 
end; 

/* Perform zero blanking */ 
Do n= to 3; 

Tf ANSWR(n)<>'@! 

then n=4; 

else ANSWR(n)=' '; 
end; 

/* Format with decimal point */ 
Call move (4,.ANGWR, TARGET) ; 
DISPLAY (4)='.'; 
DISPLAY (©) =ANSWR(4); 

end DECSREP; 


end DECSREPSMODULE; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE 


MAXIMUM 


= @VEEH 228D 
= ©6148 2D 
STACK SIZE = (4H AT) 


40 LINES READ 
f}§ PROGRAM ERROR (S) 
END OF PL/M-f8 CCOMPELATION 
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1@) 


byte; 


2¢H; 


memn— * 


* ory into a 4 digit plus 1 Cecimal ASCII display- * 
* 
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I, INTRODUCTION 


The utilization of computers to provide control or 
monitoring functions for industrial processes 
frequently results in complex computer systems. 
Distributing the control and processing intelli- 
gence throughout the control network reduces 
significantly the complexity of the system while 
increasing the reliability. The physical areas 
being controlled or monitored by each portion of 
the distributed system will generally consist of a 
relatively small number of I/O functions which 
are related by some control algorithm. 


The Intel iSBC 569 Intelligent Digital Controller 
(IDC) and the iSBC 941 Industrial Digital 
Processor (IDP) are a part of the expanding line of 
Intel products which are oriented toward filling 
the requirements of these systems. This applica- 
tion note deals with the use of these devices to 
provide control of a closed loop system using a 
version of the PID control algorithm. 


It is assumed that the reader is familiar with the 
basic concepts required to generate software and 
has had some experience with using a computer. 
This application note will then guide the reader 
through a typical application, explaining in detail 
the decisions which must be made in order to 
effectively utilize a merece puter: to provide a 
control solution. | 


The application which has been chosen is 
considered to:be typical of the type which lends 
itself to control. The mechanical aspects of the 
application will be explained so that the user not 
familiar with the particular machinery will be able 
to understand the development. It will be seen 
that the techniques used will apply to any other 
specific application. 

The emphasis of the note will be on the use and 
implementation of the hardware and software 
features of the digital processor and controller. 
The actual PID control algorithm will not be 
developed in this application note. 


Reasons for Intelligent Boards 


The advent of microcomputers and the resulting 
trend toward utilizing these devices to control 
processes has resulted in many cases where the 
overall system performance has deteriorated 
because of the demands placed on the processor. 


In these applications, the computer has become 
overburdened with control algorithms, alarm 
detection, communications, and the many other 
tasks required of it. The processor can be inter- 
rupted by time dependent tasks to the point where 
other processing tasks can not be completed. 


Presently, Intel provides two I/O expansion 
boards which are capable of handling portions of 
the processing load which formally required 
processor time. These two devices are the iSBC 
544 Intelligent Communications Controller and 
the iSBC 569 Intelligent Digital Controller. Tasks 
which involve communications or parallel digital 
I/O can now be offloaded without requiring 


valuable processor time. These boards can issue 


interrupts to the master or host processor if 
interaction with other processes or devices is 
required. This technique greatly increases system 
throughput. by offloading the other bus master 
processors and by minimizing traffic on the 
Multibus system bus. 


In some.cases, it will be found that the intelligent 


controller can function to control the process in a 


stand-alone environment, providing a more 
functional, low cost control system. 7 


The concept of offloading the processor of its 
input/output tasks can be developed on the iSBC 
569 controller through the use of slave processors 
which may be installed on the board to assist the 


-host. The result is the ability to provide up to four 


processors on a single intelligent slave I/O board 
by using the.concept of slave processors. 


The On-Board Slave Concept 

The utilization of the iSBC 569 controller is 
enhanced through the use of On Board Slave 
processors (OBS). These devices distribute the 
system intelligence and offload the processor on 
the intelligent controller. They can provide 
custom digital interfaces with the various devices 
which may be connected to the I/O ports of the 
controller. The OBS device allows a designer to 
fully specify his control/interface algorithm in the 
peripheral chip without relying on the master 
processor. Three types of OBS compatible devices 
are available from Intel. These are: 1) Industrial 
Processors, 2) Standard UPI devices, and 3) UPI 
8741A for custom applications. By combining the 
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‘devices in various combinations, optimum solu- 
tions can be generated for different control 
applications. 3 


Before proceeding, we should cover the general 
| characteristics of the OBS devices available for 
use in conjunction with the iSBC 569 controller. It 
will be seen that careful selection of the proper I/O 
controller chip can reduce significantly the design 
effort required to. provide a control solution. 


II. BASIC UNIVERSAL PERIPHERAL 
_ INTERFACE DISCUSSION 


With the introduction of the Universal Peripheral 
Interface, Intel has’ expanded the intelligent 
peripheral concept by providing an intelligent 
controller that is fully user programmable. The 
8741A is a-complete single-chip microcomputer 
which connects arent. to a master processor oe 
-bus. ‘ 


To fully understand the techniques used by the 
UPI 8741A devices, we must have a general 
knowledge of their characteristics. Only then will 
we feel comfortable in implementing a design 
which uses the components. > % 


Hardware Features 


Each Universal Peripheral tive 7 1K bytes 
of program storage plus 64 bytes of RAM memory 
for datastorage. It has a powerful, 8-bit CPU with 
a 2.5 usec cycle time and two interrupts. Over 90 
instructions are provided in its instruction 
set. Most instructions are single byte and single 
cycle and none are more than two bytes long. 
These instructions are optimized for bit manipula- 
tion and I/O operations. Special instructions are 
included to allow binary or BCD arithmetic 
operations, table lookup routines, loop counters, 
and N-way branch routines. 


The chip’ s 8- bit interval timer/event counter can 

be used to generate complex timing sequences for 
control applications or it can count external events 
such as switch closures and. position encoder 
pulses. Software timing loops can be simplified or 
eliminated by the interval timer. If enabled, an 
interrupt to the CPU can occur when the timer 
overflows. 


Two 8- bit bidirectional I/O leer are aeeiaded 
‘which are TTL compatible. Each of the 16 port 


lines can individually function as either input or 
output under software control. 

The UPI microcomputer is fully sapuetal: with 
development tools. The combination of device 
features and Intel development support make the 
8741A an ideal component for low-speed periph- 
eral control applications. 


Software Interface | 
The OBS communicates with the processor on the 


~ host board by means of data transfers between its 
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registers and the host board’s data bus. A 
communication protocol has been defined which 
provides asset of rules by which the processors may 
interact with each other. Two types of software 
protocol are currently defined. These are the 
“simple” and the ‘‘extended”’ protocol. Before 
attempting to utilize the OBS devices in an 
application, the concepts used for the communica- 
tions must be fully understood.. — 


When used on one of Intel’s single board compu- 
ters, the communication path is by means of the 
I/O ports on the host board. This means that two 
port addresses, an odd and an even location, are 
assigned to each OBS device. The even numbered 
port is used to transfer ‘‘data’”’ between the 
processors. The odd numbered port is used to write 
commands into the OBS and to read its status. 
Each transfer between the host and the slave 
device consists of the movement of eight bits = 
information. 


Four of the eight bits available in ‘the status 
message have been given predefined functions. 
The bit will be set (logical 1) when the correspond- 
ing condition exists within the OBS device and 
will be reset (logical.0) when the condition does not 
exist. The functions of the four bits are: | 


Bit-0: Output Buffer Full (OBF). 
This bit indicates that the OBS has slated 
information into the transfer register and 
that the information is available to the host 
processor. It can be read by performing an 
input operation from the even numbered port 
assigned to the particular OBS. When the 
_ data has been read, the bit will automatically 
be reset to indicate that no data is available. 
As we will see, this is one of the key features 
enabling efficient utilization of the host/ 
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slave relationships on single board compu- 
ters. 


Bit-1. Input Buffer Full (IBF). 

This bit is used to indicate that data has been 
placed into the input transfer register by the 
host device and that it has not yet been read 
by the slave. Data is transferred into the 
input register by means of the host perform- 
ing an output to the even numbered port of the 
OBS: The bit will be reset when the device 
reads the data from the input transfer 
register into its accumulator. Data should 
only be output to the OBS when the IBF bit is 
reset! 


Bit-2. FO Flag. 

_ Unlike the IBF and the OBF bits which are 
controlled by hardware, the FO bit is control- 
led by the device software. The normal 
function of the flag is to provide a lockout to 

_ prevent the host from sending more data 
until the previous data has been processed or 
the operation is complete. 


Bit-3. F1 is the Command/Data Flag. 

It is automatically set when the host sends 
either a command (odd numbered port) or 
data (even numbered port). A logical 1 
indicates that a command has been sent and 
‘a logical 0 indicates that data has been 
sent. This bit may also be cleared or toggled 
by the UPI software. 


These bits will provide normal communications 
between the master and slave processors. 


Figure 1 shows the sequence of operations which 
can be used by the host processor to establish 
communications with an OBS using the simple 
protocol. In Figure la, we see that all operations 
are initiated by the host. It will first verify that the 
IBF flag indicates that the input register is empty 
and available for receiving a command. The 
command is then sent to the odd numbered 
port. This command will inform the OBS that is to 
perform some task. The task may involve a 
requirement for more information to be sent to the 
controller and it may involve the controller 
returning some data to the host. Figure 1b shows 
the operations required for receiving data from the 
OBS. 


CLEAR CLEAR 
WRITE READ 
DATA DATA 
DONE DONE 


HOST TO SLAVE SLAVE TO HOST 


Figure 1. Simple Protocol 


With these ideas in mind, we can move to a 
discussion of representative versions of the 
devices available for use on the IDC boards. We 
will then look at a typical application to see how 
they can actually be applied to solve a problem. 


Standard Universal Peripheral Controllers 


Intel presently manufactures three UPI control- 
lers for non-industrial applications. These are: 


1. 8278 Programmable Keyboard Interface 
2. 8294 Data Encryption Unit 
3. 8295 Dot Matrix Printer Controller 


These devices offer an “off the shelf” solution to 
many applications which might be encountered. 


The Intel 8278 is a general purpose programmable 
keyboard and display interface device. The 
keyboard portion can provide a scanned interface 
to 128-key contact or capacitive-coupled key- 
boards. The keys are fully debounced with N-key 
rollover and programmable error generation on 
multiple new key closures. Keyboard entries are 
stored in an 8-character FIFO with overrun status 
indication when more than 8-characters have been 
entered. Key entries set an interrupt request 
output to the master CPU. The display portion of 
the 8278 provides a scanned display interface for 
LED, incandescent, and other popular display 
technologies. Both numeric displays and simple 
indicators may be used. The 8278 has a 16 x 4 
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display RAM which can be loaded or interrogated 
by the CPU. Both right entry calculator and left 
entry typewriter display formats are possible. 
Read and write of the display RAM can be done 
with auto-increment of the display RAM address. 


The Intel 8294 Data Encryption Unit is designed to 
encode and decode 64-bit blocks of data using the 
algorithm specified in the Federal Information 
Processing Data Encryption Standard. The DEU 
operates on 64-bit test words using a 56-bit user 
specified key to. produce 64-bit cipher words. The 
operation is reversible; if the cipher word is 
operated upon, the original test word is produced. 
Because the 8294 is compatible with the NBS 
encryption standard, it can be used in a variety of 
electronic funds transfer applications as well as 
other electronic banking and data handling 
applications where data must be encrypted. 


Finally, the Intel 8295 Dot Matrix Printer 
Controller provides an interface to the LRC 7040 
Series. dot matrix impact printers. It may also be 
used as an interface to other similar printers. The 
chip may be used i in a serial or parallel communica- 
tion mode with the host processor. Furthermore, it 
provides internal buffering of up to 40 characters 
and contains a 7 x 7 matrix character generator 
which accommodates 64 ASCII characters. 


Industrial Digital Processor 


Intel produces the iSBC 941 Industrial Digital 
Processor (IDP) which is programmed to handle 
an assortment of typical industrial digital 
interfaces and transducers. The controller can 
function to provide any of the following:. 


1. Scan up to 16 inputs for a change of state. 
_. 2, Provide up to 8 gated one-shot outputs. 
3. Provide eight gated outputs with program- 
~  mable pulse widths and periods. 
4. Provide monitoring of up to 8 input lines for 
event sensing or as a programmable divider. 
‘5. Provide the period measurement of up to 
eight inputs. 
6. Provide a frequency to count conversion of 
one input. _ 
7. Provide for the control of a stepper motor 
having up to eight phases. 
«8B. Provide a ‘Simplex. asynchronous serial 
input. 7 


9. Provide. a simplex aeynepronous serial | 
output. | 


In addition to providing one of the above 
functions, the IDP can also handle simple parallel 
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Ill. FUNCTIONS OF THE INTELLIGENT 
| DIGITAL CONTROLLER . 


The iSBC 569 Intelligent Digital Controller (IDC) 
is a versatile digital I/O processor. The IDC is 
designed to operate in a system using any one of 
the following three modes: | 


1. Intelligent Slave _ 
2. Stand-alone System 
3. Limited Bus Master 


Additional power is obtained by the utilization of 
three OBS’s to Benet? up to 48 parallel input/ 
output data lines. | 


In the intelligent divs mode, the controller’s RAM 


is shared: between the on-board 8085A and the 
Multibus users via a dual-port controller. Thus, a 
single bus master can control several intelligent 
slaves using the dual-port RAM as the major 
communications path. Switches are provided on 
the board to allow the user to reserve 1K bytes of 
RAM for use by the 569’s processor only. This 


reserved memory is not accessible via the Multibus 


system interface and pores not occupy any bus 
address space. 


In the stand-alone lode. the Satire system can 
consist of a single IDC, with cables, power supply 
and enclosure. An IDC can be installed at a 
remote site as a completely autonomous system. 


The IDC may also be operated as a limited bus 
master when ‘it. is the only bus master in the 
system. Expansion memory and I/O boards may 
be connected to the IDC via the Multibus system 
bus to increase the input/output capabilities. This 
mode could be used to configure:one IDC as a bus 
master with additional IDC’s as intelligent 
slaves. This mode is not available with any other 
bus masters such as iSBC single board: computers, 
disk controllers, “or DMA devices. 


inoue Output Functions 


The I/O interface between the iSBC 569 Intelligent 
Digital Controller and the external devices to 
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TTL INTERFACE 


8041A/8741A 
UPI 
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Figure 2. IDC Functional Block Diagram 


which it is to be connected normally consists of 


various OBS devices. Each of these slaves has the | 


ability to provide sixteen individual input and/or 
output lines. In addition, each provides two 
specialized input lines. The IDC is designed to 
accommodate up to three slave devices, so the 
normal I/O configuration of the board will consist 
of 48 digital data lines. If the specialized lines are 
considered, this number could be raised to 
54. Sockets are provided for the insertion of 
drivers or terminators for use on the 48 digital 
lines. The 6 special purpose lines can only be used 
as inputs and are provided with pull-up resistors to 
terminate the input signals. . 


The driver/termination socket configuration 
limits the grouping of the I/O lines to be in groups 
of four. Any slave data line being used for an input 
must have its output latch placed into a logical 1 
state so as to allow the input line to be controlled 
by the external signal. | oe 


IV. APPLICATION EXAMPLE 


An example of the iSBC 569 controller in an 
application will help to. explain the techniques 
used to implement a control system and to 


interface between the various functional units. 


The application chosen will consist of a typical use 
but will be simple enough to allow the design 
operations to be easily followed. 


Suppose we choose to design a control system 
which will be produced as a subsystem to interface 
with and control a liquid applicator. As we. go 
through the steps required to design and imple- 
ment such a control system, we will see how the 
various hardware and software tools which are 
available from Intel can be utilized to allow easy 
implementation of the task. 


Before proceeding, we will spend some time to 
insure there is a clear understanding about the 
definition of the liquid applicator. When this 
definition is complete, the design of the control 
subsystem can begin. 
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A liquid applicator consists of two functional 


parts: a device to. control the flow of a solid © 
material, and a device to control the flow ofaliquid _ 
onto the material. We will actually be controlling | 


two continuous process loops which are related by 


an input parameter which specifies the percentage 4 


of liquid to be applied to the dry material. 


Figure 3 shows the components making up a 


typical weighbelt feeder. The operation of the 
feeder is straightforward. The vertical gate is 
adjusted manually to provide a desired gap 


between the conveyor belt and the lower portion of | 
the gate. This will result in a nearly level © 


distribution of material on the belt when it is 
moving. The weighbelt is connected to a load cell 
to provide information back to the control system 


giving the amount of weight on the belt at any 


instant. If we know the speed of the conveyor, itis 
simple to compute the amount of material flowing 


through the feeder during any time period. This 
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flow rate is known as the Mass Flow and.is usually 


“expressed as pounds per minute. The control of 
the feeder system can be provided by varying the 


belt speed until the desired flow rate has been 
obtained. : < 


Our control system will be designed to control the 


belt speed and to monitor the weighbelt weight and 


any other parameters which we determine will be 


~ necessary to control the flow of material. A typical 


control process will require an optimum flow rate 


be established for each material of a’ different 


density. With a known material flow through the 
feeder, we can go about the process of applying the 
liquid flow to the material in order to complete our 
application example. 3 | 


The second loop of the example will involve adding 
the liquid to the material coming from the feeder 
mechanism described above. Normally, the 
percentage of material to be applied is fixed by the 
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TO MIXER © 


Figure 3. A Weighbelt Feeder 
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formula or mix design of the product which we are 
manufacturing. However, since the flow rate 
through the weighbelt feeder can and does vary 
(our first contro] loop will not always be able to 
exactly control the flow due to many conditions 
beyond our control), the liquid setpoint will 
constantly be changing as a function of the actual 
mass flow and the liquid percentage. 


Figure 4 shows the liquid application piping 
diagram for the liquid portion of the control 
system. The items with which we will be directly 
concerned are the liquid flow meter and the control 
valve. The other components, while requiring 
consideration in an actual implementation, will be 
ignored in this aplication note for the sake of 
clarity. Let us consider the details of each control 
loop in more depth before we attempt to design the 
control system. 


Mechanical Specifications 


In subsequent portions involving development of 
the control system, we will be constantly referring 
to data regarding the mechanical specifications of 
the liquid applicator system. Therefore, we will 


FROM 
WEIGHBELT 
FEEDER 


MIXERS 


LIQUID 
SUPPLY 


TANK ‘STRAINER 


PRESSURE RELIEF 
VALVE iy 


ae: 


establish a set of theoretical technical specifica- 
tions for our system. Later, we will see how close 
the control system can come to providing a control 
which meets or exceeds these parameters. These 
specifications will be broken down into two sets of 
data, one for physical parameters over which we 
have no control, and a second for the desired 
control characteristics. 


The physical data provides information on the 
mechanical design and will be used for guidelines 
in selecting interface equipment and in preparing 
software algorithms. The physical data is: 


Operating Belt Speed — 
1.1 to 180 feet per minute. maiasiea by a 
variable speed motor directly coupled to the 
belt pulley mechanism. 


Feed Output Rates — 
Adjustable over a 10:1 range with a maxi- 
mum output of 960 pounds per minute. 


Feeder Belt Characteristics — 
The belt will be 9 inches wide by 2 feet in 
length when installed. The belt pulley rollers 
will have a radius of 4.5 inches. 


MAIN AUXILIARY 
STRAINER STRAINER 


CHECK 
VALVE 


Figure 4. Liquid Flow Diagram 
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_ Feeder Weight, Sensor— — 
The weighbelt feeder will ee a strain 


-- gauge load cell to measure the weight on the. 


belt. Its. linearity. shall peer 0: 1% of full 
scale range. 


“Liquid Flow Rates — 
The liquid flow rates shall vary between 10. 0 
and 120.0 pounds per minute. — 


The desired operating characteristics of our 
control system will provide the following general 
responses; _ 


Feeder Accuracy — 
1% of full scale over a 10:1 range. The feeder 
will maintain the set feed rate within 1% of 
full scale over. any one minute period. The 
minimum sample must be at least one pound. 


Liquid Accuracy — : 
1% of full scale over the opernene range. 
Must be able to track mass flow variations 

within the above limits. 


These specifications will provide guidelines for 
the decisions which we will later make in 
providing a micro-computer control solution to the 
weighbelt feeder application. 


Interface Requirements 


A logical place to begin the consideration of the 
control system design is to examine the interface 
requirements and define the characteristics of the 
interfaces which will be required to implement the 
control. We will consider each element of the 
physical system separately. 


Weighbelt Weight 


The weighbelt weight will be sensed using a lever 
system connected to a load cell integral to the 
mechanical unit. The output of a strain. gauge 
load cell is a low level (approximately 20 millivolts 
at full scale) analog output. Obviously, this signal 
must be somehow converted into a digital level 
before we can use its information to compute the 
actual mass flow across our weighbelt feeder. Our 
design process must define the characteristics of 


the digital signal so that the appropriate analog to ~ 


digital converter system can be chosen. The 
design path can take any of several equally valid 
approaches, any of which will provide a func- 


tional control system. For the purposes of this. 


application note, we will assume that the design 
path will utilize the Intel iSBC 569 fot ligent 
Digital Processor.. : 


This assumption requires us to utilize only signals 
which can be generated or interpreted using the 
computer board and its associated OBS’s. We will 
not be capable of handling an: analog signal. 
Since some type of signal conditioning would be 
required of the low level analog voltage anyway, 


this does not impose any serious restrictions on 


our design.. Indeed, it will cause us to consider a 
technique which provides excellent noise rejection 
characteristics. We will assume that a voltage to 
frequency converter (V/F) will be installed near 
the load cell and the frequency will then be 
transmited over a pair of wires to our digital 
interface. Commercially available converters 
provide a frequency output which varies between 0 
and 10 kilohertz. With this in mind, we can 
continue with the development of the interfaces 
required 1 in the application. 


The load cell transducer will ineciuonste: a local 
unit which generates a pulse train whose fre- 
quency is proportional to the weight upon the load 


cell. This mechanical arrangement is typical of 


many gravimetric feeder systems in use today. 


For purposes of this application, it will be assumed 
that the system will be calibrated such that a 
weight of 10.00 pounds on the weighbelt will 
produce a pulse train frequency of 10 khz. No 
weight on the belt will generate a frequency of less 
than 30 hertz. The accuracy of the pulse output 
will be guaranteed to be proportional to the weight 
within 0.05%. Again, this is typical of devices 
available and in general use in similar applica- 
tions. 


The characteristics we have described above fall 
within the performance range of the iSBC 941 
processor when operated in its frequency to count 
mode. If we assume a sample rate of 200 msec 
(this value should provide an adequate control 
characteristic since it is unlikely that the 
mechanical equipment can respond rapidly 
enough to warrant a faster control and sample 
time), the frequency count read by the iSBC 941 
counter will range between 6 and 2000. System 
accuracy of reading the belt weight will thus 
exceed 0.1% of the full scale weight reading. 
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We will discuss the electrical 'and programming 
interfaces in subsequent sections of the applica- 
tion note. 


Weighbelt Motor Control 


The flow on the weighbelt will be controlled by 
changing the speed of the belt movement. Since 
the weighbelt is mechanically designed to main- 
tain a constant bed level, the amount of material 
flowing will thus be adjusted. _ 


The belt speed has traditionally been adjusted 
using either SCR controllers or by using variable 
transmissions between the motor and the con- 
veyor belt. The increased utilization and develop- 
ment of stepper motors is leading toward greater 
use of direct stepper motor drives. This is the mode 
which will be utilized for this application. 


The manufacturer’s specifications for the weigh- 
belt indicate that the following requirements exist 
for driving the device: = 


REQUIRED TORQUE — 149 LB-IN-IN 
REQUIRED MAX SPEED — 2.54 REV/SEC. 


Referring to typical manufacturer specification 
sheets for stepper motors, we find the torque vs. 
speed characteristics shown in Figure 5. Our 
application requires 2.54 revolutions/sec which 
translates to 508 steps per second when the 
stepper is used in a 1.8 degree per step mode. We 


can see that the requirements fall well within the 


capabilities of the particular motor. 


TORQUE OZ-IN — 


100 200 300 = 400. 500 
SPEED (STEPS PER SEC) 


Figure 5. Stepper Motor Torque/Speed | 


At this point, we have four routes which may be 
pursued to actually interface with the motor. These 
are: | 


1. Utilize the iSBC 941 stepper mode to drive 
the stepper motor directly. | 
2. Utilize the iSBC 941 frequency generation 
mode to drive a standard stepper translator. 
3. Utilize parallel outputs to provide a digital 
output to a stepper translater. | 
_ 4, Utilize a 4-20 ma. current signal to a stepper 
translator. 


Three of the above modes use a translator to drive 
the motor. If possible, we should strive to 
eliminate the cost of this intermediate device. 


Again, we will refer. to the published motor 
specification sheets. For our typical motor, the 
data is shown in Figure 6. The requirement for 
providing in excess of six amperes per winding 
exceeds the capabilities of the output drivers 
which can be installed on the iCS 930 termination 
board. We will be forced to either design a custom 
high power driver board or to use a translator 
module. To keep the application as simple as 
possible, we will choose the latter. 


ELECTRICAL RATINGS 1.8 DEGREE STEPPING MOTOR . 


Motor | Time for| DC | Amperes | Resistance| Inductance 
Type |One Step) Volts] Per Winding} Ohms | Millihenries 


Figure 6. Stepper Electrical Ratings 


We have three choices left when the decision has 
been made to use a translator module. The use ofa 
current output mode will necessitate the use‘of.an. 
external analog board. This is undesirable, both 
from the standpoint of interboard communication 
requirements, and from a cost effective basis. 


The use of a parallel output would commit many of 
our output data ports and would require the 
installation of UPI modules or iSBC 941 modules 
to get the parallel output drivers. In addition, 
parallel digital input is not a common option of 
commercially available translators. Oo 
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This leaves us with the use ofa variable frequency 
output. to provide stepping information to the 
translator module. This is a normal operational 
mode of the iSBC 941 processor and the required 

508 hertz is within the normal | output range of the 
device. | 


A ‘definite advantage of our aoa to use a 
stepper motor drive for the weighbelt is that we do 


not have to maintain accurate feedback and. 


control algorithms to maintain the conveyor 
speed. Only a simple check need be made to verify 
that the conveyor has not stalled. The stepper 
motor will inherently maintain a speed proper: 
tional to the frequency rate. 


The actual electrical and programming interfaces 
will be discussed in Bupgeauent sections of this 
application note. 


Weighbelt Speed Metsiusement 


We have mentioned that a control system using a 


stepper motor for speed control can operate 
effectively in an open loop configuration. How- 
ever, since a faulty component could result in 
failure of'the motor to run, we must verify that the 


belt is indeed moving. This is easily accomplished | 
by adding a magnetic sensor to the weighbelt. 


rollers and counting the pulses generated as the 
device operates. 


Typical magnetic sensors and ring magnets for 
installation on the weighbelt will provide us with 
ten pulses per revolution of a belt pulley. Since the 
pulley is operating at a maximum speed of 2.54 
revolutions per second, we will receive between 0 
and 25.4 counts per second. Using our sample 
period of 200 milliseconds, this means that we will 
count between 0 and 5 counts during each time 
interval. Our decision to use a stepper control loop 
rather than a conventional closed loop seems 
justified’ as we would obtain rather poor control 
with feedback having this poor of resolution. 


We must. fake a decision to determine how ae 
speed will be sensed by the control board. An 
obvious choice would be the use of an iSBC 941 
processor operating in the period measurement 
mode. This would require using our third socket 
on the iSBC 569 host board and would leave us 


without the ability to use an additional device to. 
support the liquid control loop. We should seek an 


alternative solution. 


The iSBC 569 controller board provides an 8253 
programmable interval timer. A first approach - 
might be to attempt to configure one of these 
counters to provide an event counting mode and 
read the belt speed from the counter. However, 
this is not possible since we would be required to 
zero the counter after each reading and the 
counter does not load the preset count until a clock 
pulse is present. We would have no ability to 
distinguish between no belt motion and the belt 
motion which is the same as the previous reading! 


An alternative approach is to create a software 
counter by routing the belt movement pulse to one 

of our interrupts and creating a program which 

will increment a counter. Each time a count is 
sensed, the software will increment a memory 

location by an increment which corresponds to the 
speed represented by one count. 


Again, we will delay hie aapuesicn of the 
electrical and programming interfaces until 
subsequent sections of this application note. 


Liquid Flow Control. 


The design of a control system to provide sian 
of flow through a liquid valveis an integral part of 
the liquid pipe and plumbing design. To optimize 
the system operation and provide a system at the 
minimum cost, the integration of control and 
mechanical design must be made. 


Several possibilities exist when making a decision 
as to which control valve to use in adjusting the 
liquid flow rate. The actual selection of the 
physical valve mechanism should be based upon 
the characteristics of the liquid flow. This 
decision is outside of the scope of this application 
note and will not be pursued. However, the valve 
actuator is a device which becomes an integral 
part of the control system and its selection is a 
function of the control system design. 


Figure 7 shows the common control valve types 
which are used to vary the flow rate of liquids. 
The automatic control system we are designing 
precludes the use of a manual valve, so we must 
make our selection between the air actuated and 
the motorized control valve. | 


Classical control design has utilized air actuated 
valves almost exclusively. This type of actuator 
incorporates an intermediate transducer to 
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Figure 7. Control Valve Family 


convert the signal generated by the control system 
into a variable air pressure. This air is used to 
drive a pneumatic control actuator. Two types of 
electrical to pneumatic transducers are in com- 
mon use. The most prevalent converts a 4 to 20 
milliampere control signal into a proportional air 
signal. The second type will accept a 0 to 10 khz 
pulse train and convert this to an air output. 


Both of the above systems provide excellent 
electrical noise immunity and give reliable 
operation in industrial environments. They do, 
however, have disadvantages. A supply of air 
must be present at the control devices and this air 
must be maintained such that it is free from water 
and oil. In many cases, this presents costly 
installation and maintenance considerations. 
The use of computerized control systems has led to 
a recent concept of eliminating the intermediate 
conversion and using instead a digitally control- 
led actuator. 


A stepper motor can be connected to the actuator 


of the control valve to provide a simple and 
economical control path. The control outputs 
from the PID control loop can be sent to the iSBC 
941 processor’s command queue and the controller 
will handle the motor movements. 


The electrical and programming interfaces of this 
interface will be fully discussed in subsequent 
sections. 


Liquid Flow Measurement 


The use of a liquid control valve to vary the liquid 
flow cannot in itself provide an accurate control 
loop. Because the flow rate through a fixed valve 
will vary with material densities, temperatures, 
and pressures, we must provide some type of 
feedback into our control algorithm. Thus, a 
flowmeter must be inserted into the liquid flow 
and its output returned to the system. 


The control system designer can choose from 
several types of flow meters depending upon his 
requirements. Figure 8 shows many of the more 
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Figure 8. Flow Meter Classifications 
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standard classifications of flow meters. Our 
selection of the meter must take into account the 


type of electrical interface available from the | 


meters. In our attempt to maintain a digital 
system which does.not require additional support 
boards, we will reject the use of a magnetic 
flowmeter because this type of meter provides an 
analog type of output which would require the 
addition of another board into our control 
system. The wobble meter provides a digital pulse 
type output but its accuracy tends to discourage its 


use in a refined control loop. We will utilize the — 


turbine meter for our liquid flow application. 


The output of a turbine meter is a low voltage, low 
current AC signal whose frequency is proportion- 
al to the liquid flow rate. The manufacturers of 
the meters provide pre-amplifiers which convert 
the signal into 10 volt peak to peak square waves 
which. are equivalent in frequenacy to the AC 
pulses. The operating frequency ranges typically 
from 100 to 1200 pulses per second. 7 


It is desirable to measure the flow rate using a 
single iSBC 569 controller. If we consider that a 
200. millisecond control interval will be used, the 
flow will result in a reading of between 20 and 240 
pulses per sample period. These readings could be 
performed using an iSBC 941 processor, but we do 
not have the socket available for a fourth module, 
so we must consider utilizing another interrupt 


driven software counter as was done with the belt — 


speed. 


All control and monitoring equipment for our 
liquid control application has now been defined in 
such a manner as to be compatible with the 
utilization of a single iSBC 569 controller 
board. The actual interfaces to perform the 
interconnections:and to provide control instruc- 
tions can soon.be considered. 


Operator Interface 


Finally, we must define the data communications. 


which must take place between the controller, 
other system tasks, and the operator. Let us first 
consider the system control variables and the data 
which, if generated by the control process, might 
be useful to the remainder of the control system. 


The first variable which comes to mind is the 
liquid flow setpoint. If we consider the entire 


~ control system, this parameter will be found to be. 


actually expressed as a percentage of the total 


- output: material. For example, if we assume the 


recipe required the final product to consist of 5% 
liquid by weight, we would require that our control 


system add the correct amount of liquid to perform 


this task. 


To allow maximum flexibility of the control 
system, we should allow selection of various 
density materials onto the weighbelt. A host 
processor with computational capabilities can 
calculate the optimum gravimetric feeder flow rate 
for the materials being combined. 


The control system can provide an integration 
function to allow totalization of the amount of 
material which has been transferred through the 
system. A capability of outputting the amount of 
material which has passed over the weighbelt and 
the amount of liquid added will be included. 


The implications of the parameter storage and 
generation will be dealt with later when the 
host/slave relationships of the iSBC 569 controller 
are discussed. 


Interface Summary 


We have defined the required interfaces adds will 
be needed to perform our control task. These can 
be grouped into external and internal interfaces. 
The external interfaces are those which connect to 
physical pieces of external equipment. 


These are summarized i in Figure 9. The internal 
interface relates to the data which is to be passed 
between the iSBC 569 Intelligent Slave board and 
other boards which may be present on the 
MULTIBUS system bus. These data areas are 
shown in Figure 10. | 


-V. HARDWARE CONFIGURATION 


We have now defined the various components 
which we will utilize on the controller board to 
support the physical control and monitor hard- 
ware. Our next task is to provide an interface 
between the controllers and the equipment which 


we are to control. In so doing, we will define the 


hardware I/O assignments for the iSBC 941 
processors and for the counters which we will be 
utilizing. The following paragraphs will deal 
with the optimization of this configuration. 
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2 ** DEVICE" ees 


** * * SIGNAL TYPE ******* 


**** BOARD ELEMENT ******** 


WEIGHBELT MOTOR 10 VDC PULSE iSBC 941 
WEIGHBELT WEIGHT 10 VDC PULSE iSBC 941 
WEIGHBELT SPEED 110 VAC PULSE - 8259A INTERRUPT 
LIQUID VALVE 5 VOC MULTIPHASE iSBC 941 
LIQUID FLOW 10 VDC PULSE 8259A INTERRUPT 


Figure 9. Control/Monitor Signals 


*** INPUTS Re eae ee eon en.) UML aK KE 
GRAVIMETRIC FLOW ACCUMULATED SOLIDS 
LIQUID PERCENTAGE ACCUMULATED LIQUID 


Figure 10. Communication Signals 


Controller Interface 


Good design practice dictates that we should 
provide optical isolation between the controller 
and the external equipment when designing foran 
industrial environment. The optical isolation is 
included if we utilize the Intel iCS series of signal 
conditioning/termination boards. We find that 
we have two types of digital termination panels 
available, one for low current, low voltage 
applications and second for higher current and 
voltage uses. If we base our choice on the data 
provided by Figure 8, we will lean toward using the 
iCS 930 panel for our interface. This board can 
handle a mixture of signal levels and will support 
up to sixteen individual lines, providing almost 
double our needs. 


Even a cursory glance at the iSBC 569 controller 
will provide the knowledge that three edge 
connectors are utilized to bring the OBS signals 
from the board. This would indicate that the 
simplest (and most costly) solution is to use three 
termination panels. Obviously, we should investi- 
gate further before making such adecision. Three 
possibilities are readily apparent. First, we might 


A ERS EFC A 


Weight In 
Conv. Mtr. 


perform some type of re-routing of data lines on 
the board so as to use only oneconnector. Second, 
we can use more than one connector on the ribbon 
cable and perform a parallel connection of the 
various lines and choose them so that no 
duplication of lines results. Finally, we can use 
some scheme of connecting three cables to the 
board and use the optional Port C connectors on 
the termination panel. 


The schematic drawings of the IDC indicate that 
only six of the OBS I/O lines of each processor 
socket are broken by wire wrap jumper posts. All 
of the lines so configured are on the Port 2 data 
lines. Unless we decide to cut etch and add 
soldered wires, we will not be able to configure our 
board with this technique. Some further investi- 
gation is in order before we can make a decision. 
The use of a parallel output technique using 
multiple connectors on a single cable seems to 
present a feasible approach if we can work out an 
assignment of I/O which will not cause conflicts. 
We will begin by building a trial port assignment 
table in which we will assign the required 
functions to input/output ports. We will group the 
inputs and outputs into groups of four to handle 
the terminator/driver arrangement which is built 
into the board. This table is shown in Figure 
11. We obviously have a small ae We have 


Valve Ph. 1 
Valve Ph. 2 
Valve Ph. 3 
Valve Ph. 4 


Figure 11. UPI™ Socket to Terminator Initial Assignments 
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not yet shown the signals from the conveyor speed 
and the liquid flow into the on-board interrupt 


counters. The schematics show that these signals — 


are brought onto the board on the edge connectors 
but the locations correspond to Port C lines which 
do not exist on the iCS 930! We have available 
input lines on the Port 1 connectors but there is no 
provision to break the signal on the board to route 
it to the counter interrupts. 


If we move on to the third alternative, we find that 
the interconnection paths caused by tieing 
various lines together cause even greater prob- 
lems. Either some fact must have been over- 
looked, or we must consider the use of more than 
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_ one terminator board. 


| Figure 11 indicates that ee ideas are available 
on the Port 2 data lines which go to jumper posts 


and which could be used if they were not part of an 
output driver of Port 20. If some technique can be 
found to use these “output” lines as inputs, our 
problem will be solved. The use of an open 
collector driver can provide us with the ability to 
use the line as an input so long as the drivers are 
turned off! This should be no problem as we can 


force the outputs to this state either through the 


appropriate jumpering of inputs or by outputting 
data to the OBS 1 ports corresponding to these 
bits. The resulting electrical configuration can be 
seen in Figure 12. 
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Figure 12. Port Assignments 20-23 
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Let us examine the implications of performing 
this interconnection. The physical layout of the 
board and the use of the terminator/driver sockets 
causes the I/O lines to be grouped into sets of four 
data lines.We must choose which of the three iSBC 
941 modules will be responsible for supporting 
each of the lines. In Figure 12, we can see that the 
belt motor is driven by OBS Socket 1, Bit 20. This 
requirement has placed output drivers onto data 
Bits 21, 22 and 23. Our requirement is to provide 
two signals which can be routed to the counter 
inputs so we must place a terminator into either 
socket Al0 or A16. We have arbitrarily chosen to 
use socket Al10. The use of the terminators in 
parallel with the drivers will not create a problem 
so long as those lines which are used as inputs 


a == —_—= eo = = P| 
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have the driver in the high impedence state. This 
is done by requiring that the output Bits 21 and 22 
of the device placed into socket 1 are driven 
low. Finally, we see that the remaining Bit 23 may 
be used as a general purpose output line if it 
becomes required. 


The wiring configurations for the remaining 
connector groupings are shown in Figures 13, 14 
and 15. In Figure 18, we see the assignments 
which can be used for Bits 10, 11, 12 and 13. We 
have earlier defined that an iSBC 941 processor 
would be used in a high speed frequency counting 
mode to determine the weighbelt weight. This 
device will be placed into socket 2. The use of this 
mode precludes the use of any general purpose 
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input/output operations of the processor if we 
desire. to maintain maximum accuracy of the 
frequency measurement. We will arbitrarily 
choose to use Bit. 10 as the location of the 


frequency count input. This will necessitate 
installing a terminator into the socket correspond- 


ing to the processor input. If required, we can 
install open collector drivers into socket A14 and 


use the remaining three bits for general purpose. 
outputs. If this is done, care must be taken to. 


assure that Bit 10 of the device which is placed into 


socket 3 is placed’into a low state as was done in. 


the preceding example. — 


The interconnection scheme for Ports 14 through 


17 can be seen in Figure 14. Note that no ports of 


this group are dedicated to our defined control 


AVAILABLE 
FOR 
INPUT OR OUTPUT 


DRIVER 
{ OR 

| TERMINATOR | 
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| functions. These four bits may be used as inputs 


or outputs as required by the application. For 
example, we have ignored the fact that actual 
control loops incorporate solenoids for flow 
control routing. The unused. bits can be used to’ 
perform these tasks. | 


Figure 15 shows the interconnections for the 
remaining group of bits. There are several 
features shown on this drawing which should be 
discussed i in some detail. Let us first consider the 
remaining function which we must implement. 

This is the control for the liquid valve stepper 
motor. An iSBC 941 IDP operating 1 in the stepper 
mode will provide the necessary control functions 
to drive the motor. Since all four of this group’ s 
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Figure 14. Port Assignments 14-17 
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data lines are committed to drive the four phases of 
the stepper motor, there are no other functions 
available. 


An important feature of the iSBC 941 processor is 
illustrated in Figure 12. This is the ability to 
enable the processor to generate an interrupt at 
some point in its operation. We have earlier 
indicated that we will use the processor in socket 2 
(the frequency counter) to provide us with a 200 
msec time reference. When the iSBC 941 proces- 
sor is enabled with an ENFLAG command and is 
operating in the frequency count mode, it will 
generate an interrupt on its output line, Port 
25. Figure 15 shows how this interrupt can be 
connected to the host board’s internal interrupt 
input structures. 


STEP SWITCH 
CONTROLLER 


The hardware configuration has been defined 
through Figure 14. The actual implementation 
can be handled through the use of the various 
wire-wrap jumpers on the IDC. Drivers and 
terminators can be installed as indicated in the 
preceding discussion. 


VI. SOFTWARE CONFIGURATION 


As with most computer controlled systems, the 
actual implementation of the task is handled with 
software. In older designs and in many mini- 
computer systems, this task has become formid- 
able and has resulted in cost over-runs and 
schedule delays. Intel provides many tools for use 
by the designer to prevent this type of problem and 
to assist him in easily creating a workable and well 


RIBBON CABLE 


OUTPUT : VALVE 
PHASE 1 
B5 
OUTPUT VALVE 
ODCS | pHASE 2 


B6 


VALVE 
| pes | pases 
opocs | VALVE 


L 
PHASE 4 


iCS 930 
TERMINATOR 


Figure 15. Port Assignments 24-27 
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documented software configuration. Let us look at 
some ofthese tools in more detail and consider how 
their use will help us to write our programe easily 
and quickly. . 


High Level Programming Languages 


A valuable tool, which Intel provides the designer 
of small control systems, is the ability to program 
even the smallest systems using a high level 
programming language, PL/M-80. This language 
offers relatively efficient and structured, program- 
ming capabilities. It has been determined that 
PL/M-80 users can expect to use between 1.1 to 
slightly more than 2 times as much program 
memory as would be used for the same task written 
in assembly language. At the same time, the 
programmer’s time to code a task will be consider- 
ably less than if he were to use assembly language. 


The PL/M-80 Programming Manual indicates 
that the language is highly structured and lends 
itself very well to handle logical type operations. 
Its weakness in. handling complex mathematical 
computations is compensated by the ability to 
combine the user application software with 
packaged Intel support software. 


Fundamental Support Packages 


The Intel 8080/8085 Fundamental Support Pack- 
age (FSP) provides a package of application 
subroutines and functions which can be called 
from programs written in either assembly lan- 
guage, PL/M-80, or in FORTRAN-80. It uses a 
standard set of data structures and a unified status 
and error reporting scheme. Nine major groups of 
operations are fully supported ny this package. 
These are: 


1. Aprimitive fast string handling and integer 
arithmetic capability without error report- 
ing. | 

2. A binary integer arithmetic package which 
performs operations on both signed and 
unsigned integers of various lengths in 
binary representation. 

3. The floating-point saihetic Sacawe 
which provides operations on floating point 
numbers in four formats: single precision, 
single-precision extended, double precision, 
and double-precision extended. . 


-.4, The decimal arithmetic routines which 
perform integer and fixed point computa- 
tions on numbers which are stored as 

| strings of ASCII characters. 

5. A string handling section which ponibainis: 

routines to transform strings and to extract 
and insert substrings. A routine for scan- 
ning of general input and one for formatting 
of general output are included. 

6. Routines for number conversion, for numer- 
ic I/O transformation of data from one 
format to another, input scanning of 
numeric strings, and formatting of numeric 
strings for output are also available. 

7. The floating point transcendental function 
section provides trigonometric, exponential, 
and other transcendental functions. 

8. The statistics routines compute the mean, 
variance, and standard deviation of one 
group of statistical data, and the covariance 
and correlation factor of two groups of data. 

9. Finally, the PID procedures provide the user 
with a version of the classical Proportional, 
Integral, Derivative control algorithm. 


Clearly, the use of the FSP support programs 
enhance the logical PL/M-80 program operations. 


Host/Slave Relationship 


Before we proceed with our development, we 
should take some time to examine the relationship 
between our iSBC 569 IDC and other controllers 
which may be installed in the system. The 
utilization of intelligent slave boards provides the 
capability to develop control concepts to an 
extremely high level if certain guidelines are 
followed. We will therefore assume that the 
control solution which we are developing will be 
but a part of an over all control concept which 
utilizes multiple controllers sharing common 
resources. | 


_ This concept allows us to sedan control algo- 


rithms for each sub-process within our overall 
control system. This development can provide 


_ independent design and implementation of each 


process. A host processor can be used to provide 
any required inter-process communication tasks 
and to provide the operator interface. We have 
previously indicated that the operator interface 
will provide some means to adjust the weighbelt 
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feeder setpoints and the liquid ratio. Itshould also 
allow the operator to display the current status of 
the process. Since these operator interface func- 
tions are but a part of the overall control functions, 
the interface should be programmed such that 
maximum flexibility can be gained through its 
use. Fortunately, such an interface is available 
using Intel’s RMX/80 BASIC-80. 


RMX/80 BASIC-80 Interpreter 


The RMX/80 BASIC-80 Interpreter is a high level 
language interpreter with extended disk capabili- 
ties. It operates on iSBC 80 Single Board Compu- 
ters and allows the interpretation of BASIC-80 
source code into an internally executable form. 
Many other features are available and many 
configurations are possible depending upon the 
exact system requirements (refer to the BASIC-80 
Reference Manual, 9800758). 


Maximum utilization of the operator interface 
with a minimum of development time can be 
achieved with the preconfigured version of the 
software/hardware package. This will provide us 
with complete disk I/O capabilities and the ability 
to easily program and maintain any programs 
which may become necessary to implement the 
interface. The actual implementation of the 
interface will be done later, after we have defined 
the control task. a 


Software Tasks 


The task of preparing the software can be broken 
down into three major groupings or tasks. These 
are defined to be: } 


Prepare the Software Drivers. 
This involves defining the relationships 
between the control algorithm parameters 
and the input/output hardware devices and 
creating software to implement these defini- 
tions. 


Prepare the Control Algorithm. : 
This will involve developing a control 
algorithm which defines the relationships 
between the various system parameters. This 
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algorithm will draw heavily upon the re- 
sources of the FSP programs and the soft- 
ware drivers which relate the parameters to - 
the physical hardware. | 


Finally, the operator interface must be defined 
which will relate the parameters used in the 
control scheme to other controllers and to the 
operator. This will allow the control task to 
interact in such a manner as to provide a 
meaningful element of the overall control 
concept. 


VII. SOFTWARE DRIVERS 


Before developing the actual control algorithm, we 
must create the drivers which communicate with 
the three iSBC 941 processors in their assigned 
operating modes. We will define two driver 
sections for each processor, one to handle the 
initialization, and a second to provide the ongoing 
communications as required by the control 
algorithm program. 


Motor Speed Control Processor 


The first processor which we will discuss is to be 
located in slave socket number 0 and will be used to 
produce a variable frequency output. Let us 
consider in some detail how this can be accom- 
plished using an iSBC 941 Processor. First, 
consider the task of initializing the device to the 
primary function operating mode, FREQ. 


Referring to the iSBC 941 Industrial Digital 
Processor User’s Guide, we find that the initializa- 
tion requires the sequence of commands and data 
shown in Figure 16. We will identify the meaning 
of each of these terms and create a software 


_ Command/Data 
Request INIT 


FREQ Select 
Scale Factor 
Output Enable > 
~ Initial State . 
P20 Delay. 
P20 Period 
Request PAUSE 


ou0u00u0un0Nn0Ng 


Figure 16. FREQ Initialization 
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program which will handle the required initializa- 
tion of the processor. The purpose and use of the 
various commands to the processor are :well 
defined in the user’s guide and will not:be repeated 
here. 


The first byte of data, which must be sent 
following the initialization command, is the data 
byte signifying that the operational mode is to be 
the frequency output. This is defined in the 
manual as being equal to the data byte “OB5H” or 
“Q35H” as expressed in the hexadecimal number- 
ing system. The choice of values to be sent is 
dependent upon our desire to utilize the internal or 


external time reference period for the operations. 


If we utilize the internal time reference, our 
minimum increment or resolution of operations 
will be 86.72 BCE ORCOUCE: 7 


To aeiseniwe if this eee is adequate for our 


frequency generator, we must consider theimpact 
that this resolution has.on the output. A 550 hertz 
signal has a period of 1.82 milliseconds. If we 
increase this period by the 86.72 microsecond time 


reference, we find that the next increment in the 


frequency generators output will be approximately 


372 hertz. This resolution is certainly not ade- 
quate to meet the motor control requirements! ‘We 


should consider using the external clock to provide 
the time reference. One of the 8253 Interval 


Timers on the iSBC 569 board’ can be used to 


generate a reference time. If we arbitrarily choose 
to use a 10 microsecond reference to the IDP, we 


find that the worst case resolution for the 550 hertz . 


signal becomes about 4 hertz.. This is certainly 


_ within: our requirements of motor control. The 


primary function eignal should then be sent asa 
“OB5H”’. » ser es 


The seasa rivei is used to establish a scale factor 


for the processor. This scale factor is used to 


generate the basic time increment which can be 
used to establish the frequency output; thati is, the 


minimum time increment which can be used to’ 
establish a period or pulse width will be ane scale 


factor times the reference time period. © 


In our case, because of the wide frequency output 
range, we cannot specify the scale factor at 
initialization (later data will show the need for 


multiple scale factor ranges). We will then only 
need to send some arbitrary value at initialization 
to allow: the Broce to opie its ee oon 
peauonee: — ote 


The Odioat uable aaa ee is need 163 naaleee 
which of the Port 2 output: bits are to be used to. 
generate the output signals. The hardware 
configuration established earlier placed the output 
onto Bit 0 of the port, so this data byte shall be 
specified as a byte having only Bit 0 set to alogical 
one or equal to O1H. | 


The Initial Outou aeusneice specifies encehe: 
each bit selected as an output by the output enable 
byte is to be initially set to a logical one or zero 
when the processor is first enabled. For this 
application, it really does not matter, but we will 
arbitrarily pick the state to be equal to zero. The: 
byte will .be defined as being set to 00H. 


The Delay parameter is used to define the 
waveform which will be generated and specifies 
the number of time increments which must elapse 
before the waveform will change states. Rather 
than to constantly vary the delay to maintain a 
square wave output, we can choose an arbitrary 
value of one time increment before changing 
state. The output will have a varying duty cycle as 
the frequency changes. This should cause no 
problems for the translator driving the weighbelt. 
motor. The byte will be defined as being set toa 
value of 01H. 


Finally, the Period of the waveform must be 
chosen. Again, this parameter will be changed 
according to the desired frequency, so: only an_ 
arbitrary value need be sent.: Indeed, since this is 
the last parameter, the value could be omitted 
entirely by eepeane the PAUSE command in its 
place. 


The initial data definition can be defined using 
PL/M-80 language conventions as a block of six 
bytes as shown in Figure 17. 


The actual communications between the host 
processor on the.iSBC 569 board and the IDP 
utilizes the protocol explained in previous sections 
of this note. The status register of the IDP will be 
tested for the bit signifying that the input buffer 
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/* DECLARATION OF iSBC 941 #0 INITIALIZATION DATA x/ 


Oo 4 DECLARE FREQ LITERALLY ‘OB5H’; 
23~«O« DECLARE SF LITERALLY ‘000H’: 
24 DECLARE OUTPUT$ENABLEOLITERALLY ‘001H’; 
25 DECLARE INITIAL$STATE — LITERALLY ‘000H’; 
26 CO DECLARE DELAY LITERALLY ‘001H’: 
7 DECLARE PERIOD LITERALLY ‘O00H’: 
/* DECLARATION OF iSBC 941 PRIMARY DATA */ 

34. DECLARE INIT$O$TABLE(6) BYTE DATA ( 

FREQ, 

SF, 

OUTPUT$ENABLEO, 

INITIAL$STATE, 

DELAY, 

PERIOD _); 


Figure 17. Initial FREQ Data Field 


full is not set. This will indicate that the device is 
ready to accept either a command or a data 
byte. The command to request a primary function 
will be sent. At this point, the processor will be 


function being selected. A “Do Loop” can be used 
to effectively transmit this data to the device. The 
program to perform this function is illustrated in 
Figure 18. 


expecting a series of data bytes as specified by the 


/x REQUEST PRIMARY FUNCTION x*/ 
44 2 DO WHILE ( (INPUT (UPISO$STATUS) AND IBF) < > 0); 
45 3 END; 
46 OUTPUT (UPI$0$COMMAND) = INITPF; 
/x LOAD INITIAL PARAMETERS */ 
47 2 DO |=0 TO 5; 
48 3 DO WHILE ( (INPUT (UPIS0$STATUS) AND IBF) < > 0); 
49 4 END; 
50 3 OUTPUT (UPISO$DATA)=INIT$O$TABLE(I); 
51 3 END; 
/x TERMINATE PARAMETER LOADING x/ 
52 DO WHILE ( (INPUT (UPISO$STATUS) AND IBF) - < > 0); 
53 3 END; 
54 2 OUTPUT (UPISO$COMMAND)=PAUSE; 
/x START FREQUENCY FUNCTION */ 
55 2 DO WHILE ( (INPUT UPI$0$STATUS) AND IBF) < > 0); 
56 3 END; 
57 2 OUTPUT (UPIS0$COMMAND)=LOOP; 


Figure 18. IDP Initialization 
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When all required data parameters have been sent, | 


the data portion of the initialization is terminated 
by sending a PAUSE command as shown in 
Figure 18. Note how, in each case before data or a 
command is sent, we wait until the input buffer is 
empty. Finally, the initialization is completed 
when we have sent the LOOP command. The 
processor will now be generating an output 
frequency as specified by the parameters. | 


Remember that, according to our earlier discus- 


sion and as we have shown in Figure 12, the 


unused output ports should be set to a logical low 
condition to allow the use of those lines as inputs to 
carry additional data into the controller. This 
should be done as a part of the initialization 
process. The secondary utility command, CLRP2 


is used for this purpose. This process is illustrated 


in Figure 19. 


We should next direct our attention to establishing 


a software interface which will take the desired 


weighbelt speed term and convert it to a frequency 
output suitable to drive the motor translator. We 
know that this will involve selecting a particular 
scale factor and period term which will generate 
the correct waveform. Previously, we established 
that, for a maximum frequency of 550 hertz, we 
need to establish a period of 1.82 milliseconds. 
Many combinations of Scale Factor and Period 
parameter will generate this time interval. Ideally, 


the smallest increment of change can be estab- 


lished by setting a constant period and modifying 
the scale factor. If we make some calculations, we 
will find that the fact that the scale factor is a byte 
value (giving us a range of between 0 and 255) 
limits the frequency range which can be produced 
using any one value for a period. It seems that we 
will be forced to vary both the period and the scale 
factor as a function of the desired frequency. 


In Figure 20, we have plotted the frequency output 
for various values of Scale Factor and Period. Our 


/x SET UNUSED BITS TO ALLOW EXPANSION  */ 


59 2 
593 END; 
60 2 
61 2 
62 3 END © 
63 2 


DO WHILE ( (INPUT UPISO$STATUS) AND IBF) < > 0); 
OUTPUT (UPI$0$COMMAND)=CLRP2; 

DO WHILE ( (INPUT (UPI$0$STATUS) AND IBF) < > 0); 
OUTPUT (UPI$O$DATA)=INITIAL$OUTPUT, 


Figure 19. Secondary Utility Command 


SF —> 
_ 
rs 
=) 


CLOCK - 10 usec 


' 300 400 500 


FREQ. —> (Hz) 


Figure 20. Frequency Vs. Parameters 
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intent is to maintain the highest resolution 
possible for the desired output range of 50 to 550 
hertz. Choosing four period base parameters will 
provide us with acceptable waveform generation 
characteristics. We will choose the data sets of 
Figure 21 based upon the data shown in Figure 20. 


The Period can be determined by examining the 
desired frequency range. The scale factor can be 
calculated from the equation: 


SF = 10,000 / ( (FREQUENCY) x (PERIOD) ) 


Again, the PL/M-80 language program to imple- 
ment the interface between the host and the IDP is 
easily constructed. For example; Figure 22 
provides the- code which will be required to 
determine the appropriate Period parameter and 
also illustrates the use of FSP programs to handle 


Frequency Period 
~ 60 to 165 Hz. 9 
166 to 225 Hz 5 
- 226 to 285 Hz. 3 
2 


286 to 550 Hz. 


Figure 21. FREQ Output Ranges 


the mathematical calculations required to deter- 
mine the corresponding scale factor. 


The principles above can be expanded into a 
complete interface package to offload the host 
processor of the need to generate the frequency 
waveform to the translator of the weighbelt 
motor. The complete program for the processor 
can be found in Appendix A. 


Weight Input Processor 


The second use of an iSBC 941 Processor is to 
provide the capability of converting the high 
frequency inputs from the weight sensor of the 
weighbelt into a digital value equivalent to the 
actual weight on the belt. This frequency to digital 
conversion can be easily accomplished by the use 
of the Primary Function; FCOUNT. 


- Scale Factor Resolution 
221 to 67 3 Hz. 
121 to 89 3 Hz. 
147 to 117 3 Hz. 
175 to 91 


6 Hz. 


|* COMPUTATION OF FREQUENCY RANGE */ 


B78 IF FREQ < 285 
THEN DO: 
59 4 IF FREQ < 226 
THEN DO: 
61 «5 IF FREQ <166 - 
_ THEN RANGE = 9: 
63. «5 ELSE RANGE = 5: 
64 5 END; 
65. 4 ELSE RANGE =3: 
66 «4 END: - 
67 3 ELSE RANGE = 2: 
/* LOAD MATH ACCUMULATOR WITH 100,000 */ 
68 3 CALL MQULD4 (.IR,.HUNDRED$K): 
/*« TEST FOR MOTOR SHUTDOWN */ 
69 «3 IF FREQ >1 
THEN DO: 
/* DIVIDE BY FREQUENCY «/ 
71. 4 CALL MQUDV2 (.IR,.FREQ); 
/* DIVIDE BY RANGE FACTOR */ 
72 4 - CALL MQUDV1 (.IR,.RANGE); 
_/* GET TWO’S COMPLEMENT FOR iSBC 941:-SCALE FACTOR */ 
73. «4 | CALL MQUST1 (.IR,.FREQA); 
74 4 FREQA=NOT (FREQA + 1); 
ae 


END; 


Figure 22. Period and Scale Factor Computations 
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The FCOUNT Primary Function is selected by. 
sending the INITPF command followed by four’ 


parameters. The process is identical to that which 


was used in the previous example when we 


established the FREQ function. In this case, the 


sequence is described in the manual as is shown in. 


Figure 23. 


Description 


Command/Data 


Request INIT 
Select FCOUNT 
Input Select — 
Output Enable 
Sampling Interval ' - 
Request PAUSE 


Figure 23. FCOUNT Initialization 


Let us examine the derivation of the terms which | 


must make up the data table which will be 
transmitted to the processor in order to initialize 
it. The FCOUNT function does not allow the use 
of an external clock so we have no option as to 
which command will be sent to select this 
function. It is defined to be equal to 33H. This 


becomes the first element of the byte array used to - | 


contain the initial data. 


The Input Select parameter describes which of the 
Port 1 inputs are to be measured. If we refer to 
Figure 13, we can see that a hardware assignment 
of Port 10 has been made for this function. This 


assignment corresponds to bit 0 of the parameter 7 


being set to a value of 1. The byte value for this 
parameter then becomes 01H. 


The Output Enable byte is used to enable an output 
port corresponding with the input to change states 
when the Sampling Interval time has elapsed. Our 
system has a requirement to operate the control 
algorithm once each 200 milliseconds and we have 
previously indicated that the frequency counter 
would be used to establish this time interval. Ifthe 
output is enabled and connected to an interrupt 


line, it will provide our system with the required. 

pacer clock. The output bit from Port 20 will then | 
be enabled to provide the interrupt. The para- _ 
meter for this byte will be set to the same value a as | 


the Input Select and becomes 01H. 


The Sampling Interval will establish the time 


interval to be used when sampling the input. 


frequency. This time interval should be set to 200 


milliseconds for our application. The parameter) is 
then eae from 1 the cane nen | , 


INTERV eT (SAMPLE PERIOD) / © eee) 
OR — 


~EMTERV ALS (0.200) / (0.02222) = 


The correct saianliay interval for our ential 
system should be set to a value of 09H. 


A similar procedure can be used to send this data 
to the processor. The actual code used to imple- 
ment the system can. be found in Appendix 
A. Note that the unused bits of the device have 
been set to a predetermined value as was indicated 
by our hardware design of Figure 13. 


Once the processor has been initiated and is 
performing its function, we need only wait until 
the device signals us that the 200 millisecond time 
interval has passed and that it is ready with the 
belt weight. When this interrupt occurs, we will 
read the data and perform our control functions. 


‘An interface must be established between the 


contro] algorithm and the processor which 
enables it to receive a value which represents the 
actual weight. 


The total count received by the processor is 


available as a sixteen bit count made up of two 


eight bit bytes. The use of the Secondary Utility 


Commands, Read FCOUNT Measurements 
(RDFCO-RDFCF) allow the two bytes to be 
transferred into the host processor. We are using 


the first counter so we will use the corresponding 
commands, RDFCO and RDFC1. An example of 


_ the procedure to read one of the count. bytes can be 


seen in Figure 24. 


The counter can be commanded to begin its next 
sample period by issuing a LOOP command to the 


‘processor. The two data bytes can be combined to 


form a 16-bit word and the resultant value divided 


by 2 to form a weight value. The division by two to 


obtain weight is required since the count range 
from 0 to 2000 corresponds to a weight of between 0 
and 10.00 pounds; thus, each count has a value of 
0.005 pounds. The integer numbers used in the 
control algorithm are fixed point with an implied 


scale factor of 100. The division by two provides a 
_ result which meets the criteria. 
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/x GET INPUT COUNT LOW BYTE */ . 


106 2 
107 3 END; 
108 2 
109 2 
110 3 END; 
111 2 


OUTPUT (UPI$1$COMMAND) = 


DO WHILE ( (INPUT (UPI$1$STATUS) AND IBF) < > 0); 


RDFCO; 


DO WHILE ( (INPUT$1$STATUS) AND OBF) = 0); 


LCOUNT = INPUT (UPIST$DATA), 


Figure 24. FCOUNT Read Procedure 


Appendix A ee the complete listing of the 
code which was used to interface with the 
processor assigned to the primary function, 


FCOUNT. 
Stepper Motor Control Processor . 


The third example of utilizing the iSBC 941 
Processor in an industrial application is provided 
by the processor installed into OBS socket 2. This 
device is used to drive a stepper motor which, in 
turn, controls the liquid Valve position. Again, we 
will break the discussion into an initialization and 
an interface operational mode. 


We find that the User’s Guide indicates that 
initialization to the STEPPER Primary Function 
is performed by sending the INIT command 
followed by up to 21 data bytes. Figure 25 
provides the table which shows the meceeery 
parameters for this mode. 7 


The technique used to place the processor into the 
desired function is the same as we have seen with 
the two other processors so we will not spend time 
dealing with the communications sequence. In- 
stead, we will examine the techniques which can 
be used to determine the values of the initializa- 
tion parameter bytes. 


STEPPER is requested by sending a data byte of 
either 17H or 97H following the INIT command. 

Remember that the significance of setting bit 7 of 
the data high is to request that an external clock 
be used by the processor. There is no reason to use 
an external clock for our application, so we can 
choose a function request byte of 17H. 


The remainder of the data is used to define the 
waveforms which are necessary to drive the 
stepper motor. We will derive the values for these 
parameters by beginning with the manufacturer’s 
data sheet and moving until we have determined 
the correct value for each byte of data. 


The motor chosen for this application utilizes four 
phases to drive the shaft. The data sheet provided 
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Command/Data 


Description 


Request INIT 
Select STEPPER 
Select Scale Factor 
Output Enable 
Output Polarity 
Common Period 
P20TRAN1 
P20TRAN2 
P21TRAN1 
P21TRAN2 
P22TRAN1 
P22TRAN2 
P23TRAN1 
P23TRAN2 
P24TRAN1 
P24TRAN2 
P25TRAN1 
P25TRAN2 
P26TRAN1 
P26TRAN2 
P27TRAN1 
P27TRAN2 
Request PAUSE 


Se) 


OQvuvVVVVVVVGCVC0C0O0000000 


Figure 25. STEPPER Function Initialization 


information for both a Four-Step Input Sequence 
(1.8 degrees per step) and for an Kight-Step Input 
Sequence (0.9 degrees per step). We will use the 1.8 
degree step angles for our example and applica- 
tion. The data provided by the manufacturer is 
shown in Figure 26. The first task is to convert the 
switch state diagram into a desired waveform for 
each of the four phases. This has been done in 
Figure 27 : 


Beginning with Scale Factor, let us determine the 
required data parameters which will ‘yield a 
stepper controller compatible with our motor. The 
Scale Factor will provide the minimum time 
period for one step to take place. The minimum 
time which we can specify is a function of both the 
motor characteristics and of the TRP for the 
primary function, STEPPER. The minimum TRP 
is determined by referencing the IDP User’s Guide 
for the desired function. In this case, it is found to 
be 325 + (13 x.B) where B is the number of phases 
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_ . DC STEPPING CIRCUIT 


EIGHT-STEP INPUT SEQUENCE 


Figure 26. STEPPER Motor suse Séquence 
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PHASE1 a 
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Figure 27. STEPPER. Motor Waveforms 


which are used. The result will be expressed in 
terms of processor cycles and can be converted 
into time by multiplying by 2.71 microseconds | per 
cycle. This works out to be: 


325 + (18 x 4) = 877 PROCESSOR CYCLES 
OR 
377 «2.71 = 1.021 MILLISECONDS — 


Now, let’s examine the minimum time which can 
be utilized by the stepper motor. This is given in 
the manufactuer’s data sheets as being 2.86 milli- 
seconds for the motor which we have chosen to 


use. This value must be asad to Saat the Seale 


Factor for this application: The Scale Factor is 
computed by dividing the minimum step time by 
86.72 microseconds or: | 


SF=2.86 MILLISECONDS/86.72 MICROSECONDS=33 | 


This number is entered into the processor using 
two’s complement which becomes equal to ODFH. 


The Output Enable is used to specify which of the 
eight possible control outputs are to be used to 
control the motor phases. The motor phase 
assignments to I/O ports was made in Figure 15 


and indicates that Ports 24 through 27 will be 


enabled for the primary function. Setting the 
corresponding bits provides a parameter to be sent 


to the processor of OFOH. 


The rest of the parameters deal with providing a 
definition of the waveforms generated in Figure 26 


to the processor. The following paragraphs deal 
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with the operations required to convert the 
graphic representation into data parameters. 

Each phase must be initialized toan initial output 
state which corresponds to the signal level shown 
for Step 0 of Figure 27. A “1” will be placed into 
the bit corresponding to each of the port’s output 
bits which are to be in a logical one state upon 
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reaching step 0. We see that Bits 24 and 26 are set 
corresponding to phase 1 and 3. The data byte for 
Initial Output is thus defined to be 050H. 


The Period parameter for a stepper motor function 
corresponds to the number of steps which are 
defined in the motor’s step sequence. Ourexample 
uses a four step sequence so the Common Period 
will be set to a value of 04H. 


The remainder of the initialization parameters 
define the transitions of each of the phases. This 
involves the examination of the waveform and 
noting the points at which the output level 
changes. This data can be input to allow the 
device to accurately produce the control wave- 
forms for any stepper motor control mode. We are 
not using the first four output bits so the transition 
definitions for these outputs is meaningless and 
will be output as zeroes. The waveform for output 
Port 24 shows a transition at steps 1 and 3. The 
parameter for the first transition of Port 24, 
P24TRAN1 is defined to be OOH. Likewise, the 
second transition, P24TRAN2 is set to a value of 
02H. 7 


The technique used above can be continued to 
define the constants, P25TRAN1 and P25TRAN2 
as being the same as for Port 24 or 00H and 02H 
respectively. . 


The transitions for the phases driven from Port 26 
and 27 can be seen to occur at steps 1 and 3 so the 


data for those parameters can easily be seen to be © 


set to 01H and 03H for each port. 


The initialization table can be sent to the 
processor using the same techniques as were used 


for the processors discussed previously. The 
complete program for the initialization can be 
found in Appendix A. 


A driver must next be prepared which will be used 
to provide the interface between the control 
algorithm and the IDP processor which supports 
the stepper motor. When the STEPPER primary 
function is used, a queue is utilized for supporting 
the step commands to the motor. Each command 
to the stepper consists of a data byte signifying the 
step rate to be used and a data byte which provides 
the signed magnitude of the number of steps to be 
moved. Using the motor to control a flow control 
valve allows us to use a constant step rate, but 
some type of program must be prepared which will 
convert the signed two’s complement representa- 
tion of the position from the control algorithm toa 
signed magnitude format. 


The number conversion is easily done and the 
PL/M-80 programming code to perform the format 
change is shown in Figure 28. | 


The data queue allows up to six movement 
commands to be present and waiting to be 
serviced by the IDP. If the processor is behind in 
its operations and cannot accept a seventh 
request, the host must wait until one of the 
requests in the queue has been serviced. The 
queue status bits can be tested to determine if room 
exists for another command and the ‘queue not 
empty” bit can be tested to verify that all 
requested movements have been completed. 
Normal operation of our motor should be such that 
the queue is not allowed to fill to its maximum 
capacity. 


/x SUPPORT CONVERSION TO SIGNED MAGNITUDE NUMBER */ 


141 3 IF POSITION > 127 | 
THEN DO; 
/x GET MAGNITUDE OF MOVEMENT */ 
143 4 POSITION = 256 - POSITION; 
/x SET SIGN FOR CCW ROTATION +/ 
144. «4 POSITION = POSITION OR REVERSE; 
145 4 END; 


Figure 28. Number Format Conversion 
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The code which is required to test the queue and to. 


send a stepper movement request is. shown in 
Figure 29. The complete code. can be seen in 
Appendix A. 


VIII. APPLICATION SOFTWARE 


Having developed the software which is required . 


to support the Industrial Digital Processors, we 
can now devote our time to the task of implement- 
ing the application software and of handling any 
programs which are required to support functions 
unique to the host iSBC 569 board: This software 
can be grouped into two general categories, 
initialization programs, and control algorithm 
programs. 


Initialization Programs 


The initialization of the iSBC 569 involves setting 
up the required configuration of interrupt hand- 
ling and of the devices which are installed into the 
slave sockets. For the purposes of this applica- 
tion, we will include some system diagnostic 
capabilities within the process. These routines 
will be executed each time a RESET or a POWER- 


UP occurs. Only the highlights of the code used. 


will be presented in detail; however, the complete 
listings of the initialization programs can be 
found in Appendix A by pe to the oe 
Program listing. — 


A unique feature of using the iSBC 941 processors 
is their ability to provide, upon request, an 


Nn oo 


identification code. The initiation diagnostic 


program takes advantage of this fact by interro- 
gating each processor and_.verifying that the 
correct ID code is returned. If any of the proces- 
sors have failed:catastrophically or if the internal 
data bus of the host board has failed, the program 
will provide an ean of this fact. 


Bach of ihe pene processors tae: saaeeiated with 
it, an individual hardware reset line which is 
under the control of the host. A reset or power up 
condition will cause the control lines to reset to the 
state which hold each slavei in a reset state. Before 
any slave can be used, it’s associated reset line 
must be de-activated. This is done by sending a 
logical one to the corresponding bit of the Reset 
Latch. Other bits of the Reset Latch can be used to 
illuminate the on-board LED or to generate an 
interrupt to another board on the Multibus data 
bus. | 7 _ 


A special PL/M-80 command is utilized to disable 
the reset interrupts of the 8085A host processor. 


Execution of this command will allow all servic- 


able interrupts to enter via the 8259A Interrupt 
Controller. The command which will mask off the 
unused interrupt structure is shown in Figure 30. 


The initialization process must also initialize the 
FSP Integer Record. This will allow the use of the 
math support routines which will be required to 
support the ie algorithm. 


| VERIFY THAT QUEUE SPACE IS AVAILABLE +/ 
DO WHILE ( (INPUT (UPIS2SSTATUS) AND QF) < > 0): 


DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) < > 0): 
OUTPUT (UPI$2$DATA) = STEPSRATE; 


DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) < > 0): 


= POSITION; 


Figure 29. STEPPER Movement Request 


/* MASK OUT THE RESET INTERRUPTS OF THE PROCESSOR ¥*/ 


446 
147. END; 
/x REQUEST DESIRED STEP RATE */ 
148 3 
149 4 END; 
150 3 
/x REQUEST STEPPER MOVEMENT e) 
1513 
152 4 END; 
153 3 OUTPUT aaa ee 
34 CALL S$MASK (MASKS); 


Figure 30. PL/M-80 Sim Instruction. 
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Control Algorithm Programs 


The program which actually handles the control 
algorithm for the two loops can be found in 
Appendix A, MAIN$CONTROL. The flow of the 
program is straightforward and can easily be 
followed by reading the listing. The operations 
are primarily handled by the use of repeated calls 
to the FSP integer math routines and to the 
processor interface modules which we have 
previously generated. | 


It is beyond the scope of this application note to 
dwell upon the techniques which were used to 
generate the PID control routine; this aspect will 
be covered in a future application note. 


Limits were placed upon the control outputs so 
that the signals to the processors would not exceed 
the physical limits of the external devices. For 
example, the frequency range is limited to range 
between 0 and 550 to correspond with the 
operating range of the weighbelt as we have 
defined it. The limits upon the liquid control valve 
have been set at plus and minus 10 steps since this 
is the maximum distance which the stepper motor 
can travel in any one 200 millisecond time period; 
increasing the possible count could result in filling 
the queue. This could cause the 200 millisecond 
time to be extended if we had to wait for the queue 
to empty. 


Master Processor 


A complete control solution to the weighbelt feeder 
and the liquid applicator has now been developed. 
The process is stand alone and resides entirely 
upon a single board. It can operate without 
requiring any access from the MULTIBUS bus, 
thus freeing the bus for other control, monitoring 
or supervisory duties. 


The system developed for this application note 
requires a setpoint for the mass flow and a liquid 
ratio be provided to the control system. This 
information would normally be supplied by some 
type of bus master device. We have chosen to use 
the pre-configured RMX/80 BASIC-80 Interpreter 
to perform this task. A simple program needs to 
be prepared which will allow adjustment of the 
setpoints and monitoring of the operation of the 
control system. 


Using BASIC will provide full disk I/O capabil- 
ities to the operator. Communicating with the 


system through a CRT terminal, he can write and 
execute programs which use the resources of the 
system disk or of any of thecontrollers which may 
be present on the bus. 


Two programs are required to perform this 
task. Since they are written in BASIC, they may 
easily be modified or expanded if the need should 
ever arise. Indeed, other programs could be 
written to perform other tasks, such as optimizing 
the control parameters. 


In both programs, the parameters involved with 
the control operation are accessed by using the 
PEEK and POKE instructions. Remember that 
the iSBC 569 controller allows the on-board 
memory to be made available to other devices on 
the bus through the dual port mechanism. In our 
application, this has been done by jumpering the 
board such that the on-board memory beginning 
at location 8000H can be accessed on the bus at 
location 2000H. This mapping was done since the 
memory locations at 2000H are not used by BASIC 
unless requested to do so. A byte of data which is 
at location 827EH on the controller can be read by 
performing a PEEK of location 227EH. Some of 
the memory assignments for the controller have 
been shown in Figure 31. 


MOD MAINCONTROLMODULE 


829FH SYM MEMORY 
8233H SYM PRLQ 


825 FH SYM CONSTANT$1 
O0ODCH SYM BOUNDS2 
OOE6H ~° SYM TIMEINTERVAL 
827AH SYM LIQUIDFLOW 
OOE 8H SYM DISTREV 
8280H SYM MASSFLOW 
8285H SYM LIQUIDVALVE 

- 8288H SYM DUMMY 


OOEFH SYM ZERO 
01ADH SYM 
81F 7H SYM IR 


825DH SYM LIQQGOUNT 

826 8H SYM CONSTANTS2 
OOE 4H SYM CONTROL1 
8277H SYM BELTSPEED 
827CH SYM MASSSETPOINT 
OOE 9H SYM CONVLENGTH 


828 2H SYM BELTCONTROL 
8287H SYM SYSTEMRUNNING 
828AH SYM ICW 

3FOOH SYM JUMPTABLE 
8209H SYM PRCV 


825EH SYM BELTCOUNT 
00D 4H SYM BOUNDS1 
OOE 5H SYM CONTROL2 
827 8H SYM BELTWE!IGHT 
827EH SYM SETPOINT 


OOEAH SYM SIX 


828 4H SYM LIQUIDRATIO 
OOE BH SYM ERRORFIELD 
OOEDH SYM THOUSAND 
OOF 1H SYM INITIATION 


_. Figure 31. Selected Memory Location Assignments 
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The first program involves setting up the two 
control parameters and handling the control flag 
which causes the process to start and to stop. This 
program can be found in Figure 32. 


10 REM THIS PROGRAM IS USED TO INPUT SETPOINTS 
15 REM TO THE LIQUID CONTROL SYSTEM. 
20 POKE 02287H,0 

25 INPUT “ENTER MASS SETPOINT-”;MS 

26 IF MS > 1200 THEN 25 

30 MS=CINT(MSx10/60) 

35 H=INT(MS/256) 

40 L=CINT(MS-Hx256) 

45 POKE 0227EH,L 

50 POKE 0227FH,H 

55 INPUT “PERCENT LIQUID-”;LR 

60 LR=CINT(LR) 

65 IF LR > 127 THEN 55 

70 POKE 02284H,LR 

75 POKE 02287H, 1 

80 RUN “STATUS” 


Figure 32. Basic Program for Parameter Initialization 


PROGRAM NAME: STATUS 


10 |=PEEK(0227EH) 
20 H=PEEK (0227FH) 
30 MS=((256xH)+L)x60/10 — 
40 L=PEEK(02278h) 
50 H=PEEK(02279H) 
60 WT=((256xH)+L)/100 
70 L=PEEK(022890H) 
80 H=PEEK(02281H) 
90 AM=((256xH)+L)60/10 
100 MT=PEEK(02294H) 
110 LR=(PEEK(02284H))/100 
120 LS=AMxLR 
130 L=PEEK(0227AH) 
140 H=PEEK(0227BH) 
150 LF=((256xH)+L)/100 


Upon completion of the initialization program, a 
second program provides a display of the system 
operation. This program could have been an 
optional program which i is only called when the 
operator desires to view the system operation. A 
program which provides a snapshot of the system 
operation is shown in Figure 33. Again, the 
program is interactive with the operator and can 
easily be modified at. any time to reformat or 
display additional information. | 


IX. CONCLUSION 


The purpose of this application note has been to 
demonstrate some of the techniques which can be 
used to provide a control system design solution 
using an intelligent slave concept. This has been 
done and the system has been constructed and has 
been found to operate as the design specified. The 
Intelligent Slave Concept does provide a single 
board solution to distributed control and certainly 
offloads the master processor of control duties. 


160 PRINT “MASS SETPOINT” ,“WEIGHT”,“ACTUAL MASS”,“MOTION” 


170 PRINT MS,WT,AM,MT 


180 PRINT “LIQUID RATIO”,“LIQUID SET”,“LIQUID FLOW” 


190 PRINT LR,LS,LF 

200 Z=PEEK(02285H) 

210 IF Z< 128 THEN 230 
220 Z=256-Z 

225 Z=0-Z 

230 L=PEEK(02282H) 

231 H=PEEK(02283H) 

932 BS=((256xH) +L)x60/200 


239 PRINT “STEPPER”;Z, “BELT’;BS 


240 PRINT “” 

250 PRINT “” 

260 FOR N=0 to 1000 
270 NEXT N 

280 GO TO 10 


Figure 33.: Basic Snapshot Program | 
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This frees the master to provide supervisory 
control and human interface duties. 


Certainly, this concept can be expanded to 
encompass a broad variety of complex control 
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situations. At the same time, there is no reason 
why the Intelligent Slave board could not be used 
to provide a single board solution to a simple 
control application where no interaction with 
other processes is required. 
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APPENDIX A 
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ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE BACKGROUNDMODULE 

OBJECT MODULE PLACED IN :F1:BCKGND.OBJ | : 

COMPILER INVOKED BY: PLM8@ :F1:BCKGND.PLM DEBUG PAGEWIDTH(72) TITLE('BA 
-CKGROUND PROGRAM' ) 


J RRRRRERRRERERRKER RE RRR EERE RE REREREKKEEKKEEKE 


* THIS IS THE MAIN BACKGROUND OPERATING me 


* PROGRAM FOR THE PID CONTROL SYSTEM. “ 
RRA KK KKK KK KERR R EKER RRR EKER RRR ERE ERRRKKEE / 


1 BACKGROUNDSMODULE: DO; 
/* DECLARATION OF BOARD I/O ASSIGNMENTS */ 
2 | DECLARE UPIS@$STATUS LITERALLY '@ES5H'; 
. 4 DECLARE UPIS1SSTATUS LITERALLY 'QE7H'; 
4] DECLARE UPIS2$STATUS LITERALLY '@EQH'; 
> 4 DECLARE UPIS@$COMMAND LITERALLY 'QESH'; 
6 i DECLARE UPIS1SCOMMAND LITERALLY 'QE7H'; 
7 4 DECLARE UPIS2$COMMAND LITERALLY '@EOH'; 
8g ] DECLARE UPIS@SDATA LITERALLY '@E4H'; 
9 ] DECLARE UPIS1SDATA LITERALLY 'QE6H'; 
iw 1 DECLARE UPIS2$DATA LITERALLY '@E8H'; 
ii DECLARE RESETSLATCHSADR LITERALLY '@EAH'; 
/* DECLARATION OF RAM TEST PARAMETERS */ 
12 1 DECLARE BEGINSRAM LITERALLY '8@@0H'; 
i: 4 DECLARE ENDSRAM LITERALLY '85@@H'; 
14. DECLARE ZEROSPATTERN LITERALLY '@Q@H'; 
is. 1 DECLARE ONESSPATTERN LITERALLY '@FFH'; 
/* DECLARATION OF RESET LATCH BIT ASSIGNMENTS */ 
i ae DECLARE RESETSUPI$@ LITERALLY '@Q020GG1B'; 
ig « DECLARE RESETSUPI$1 LITERALLY 'G@@2GG10B'; 
181 DECLARE RESETSUPIS$2 LITERALLY '@@G9G100B'; 
1 j DECLARE LIGHTSLED LITERALLY '@@@@19GGB'; 
20 1 DECLARE MULTISINTR LITERALLY 'OPG1G@RGB'; 
/* DECLARATION OF ISBC 941 STATUS BITS */ 
21 #1 DECLARE IBF LITERALLY '@@OGG@1GB'; 
22 DECLARE OBF LITERALLY 'O9@@0001B'; 
/* DECLARATION OF ISBC 941 COMMANDS */ 
23 1 DECLARE IDEN LITERALLY '@O@H'; 
/* DECLARATION OF ISBC 941 IDENTIFICATION CODE */ 
24] DECLARE SBCQ41 LITERALLY '41H'; 
/* DECLARATION OF MEMORY TEST ADDRESS REGISTER */ 
5 DECLARE I ADDRESS AT (87FEH); 
6 1 DECLARE MEMLOC BASED I BYTE; 


/* DECLARATION OF RESET MASKS FOR 8685 PROCESSOR */ 
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No DB ee 


NOR RR BD 


NR toh & pr 


/* 


/* 


/* 


/* 


/* 


/* 


/* 


/* 


DECLARE MASKS BYTE DATA (@@FH); 


DECLARATION OF PL/M-8@ SIM INSTRUCTION */ 
SSMASK: PROCEDURE (MASK) EXTERNAL; 
DECLARE MASK BYTE; 
END SSMASK; 


DECLARATION OF INITIATION TASK */ 
INITIATION: 
PROCEDURE EXTERNAL; 
END INITIATION; 


CLEAR ISBC 941 DEVICES USING ON-BOARD RESET */ 
OUTPUT (RESETSLATCHSADR) = @; 


MASK OUT THE RESET INTERRUPTS OF THE PROCESSOR */ 
CALL SSMASK (MASKS); 


TEST MEMORY RAM LOCATIONS */ 
DO I = BEGINSRAM TO ENDSRAM; 
MEMLOC = ZEROSPATTERN; 
DO WHILE MEMLOC <> ZEROSPATTERN; 
END; 


MEMLOC = ONESSPATTERN; 
DO WBILE MEMLOC <> ONESSPATTERN; 
END; 

END; 


RELEASE 941 LOCKOUT/RESET BITS */ 
OUTPUT (RESETSLATCHSADR) = RESETSUPIS$@ OR 
RESETSUPI$1 OR 
RESETSUPIS$2 OR 
MULTISINTR; 


VERIFY THAT SBC941 PROCESSOR IS IN SOCKET @ */ 
DO WHILE ((INPUT (UPIS@SSTATUS) AND IBF) <> @); 
END; 

OUTPUT (UPIS@SCOMMAND) = IDEN; 

DO WHILE ((INPUT (UPIS@SSTATUS) AND OBF) = @); 
END; 

DO WHILE (INPUT (UPIS@SDATA) <> SBC941); 

END; 


VERIFY THAT SBC941 PROCESSOR IS IN SOCKET 1 */ 
DO WHILE ((INPUT (UPISISSTATUS) AND IBF) <> @); 
END; 

OUTPUT (UPIS1SCOMMAND) = IDEN; 

DO WHILE ((INPUT (UPISI1SSTATUS) AND OBF) 
END; 

DO WHILE (INPUT (UPISISDATA) <> SBC941); 
END; 


Q); 
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/* VERIFY THAT SBC941 PROCESSOR IS IN SOCKET 2 #*/ | 


58 1 DO WHILE ( (INPUT eee AND IBF) <> @); 
59 2%, END; | 

68 l- OUTPUT. -(UPI$2$COMMAND) IDEN; | : 
61 ] DO WHILE ((INPUT | (UPIS2SSTATUS) AND OBF) = 0); 
62 2 END; 

63 1 DO WHILE (INPUT (UPIS2SDATA) <> SBC941); 

64 2 END; | 


/* START-UP TEST OK- TURN OFF LED */ 
65 i OUTPUT (RESETSLATCHSADR) = RESETSUPIS@ OR 
RESETSUPIS$1 OR 
‘-RESETSUPIS2 OR 
LIGHTSLED OR 


MULTISINTR; 
/* INITIATE THE CONTROL DEVICES */ 
66 1 CALL INITIATION; 
/* PERFORM. BACKGROUND TASKS ‘y 
67 Jl DO WHILE 1; 
68 2 HALT; 
69 2 END; 


7% 1 END BACKGROUNDSMODULE; 


MODULE INFORMATION: 


Q@@D4H + 212d. 


CODE AREA SIZE = 
VARIABLE AREA SIZE = @€@@H @D 
MAXIMUM STACK SIZE = @#@2H 2D 


128 LINES READ 
@ PROGRAM ERROR (S) 


END OF PL/M-8@ COMPILATION 
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ds 


~] OV 


ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE MAINCONTROLMODULE 
OBJECT MODULE PLACED IN :F1:CNTTSK.OBJ 
COMPILER INVOKED BY: PLM8@ :F1:CNTTSK.PLM DEBUG 


NO dO 


NO NO 


SINTVECTOR (4, 3F@0H) 

$PAGEWIDTH (72) 

STITLE('MAIN CONTROL") 

[RRR RRERKERE KERR EERE EER KERR ER EKRKEEKRKERKEKEKEEKEKKEKKEEKE 
* MAINSCONTROLSTASK 

* THIS TASK IS USED TO CONTROL THE TWO PID CONTROL 

* LOOPS. ONE LOOP CONTROLS THE SPEED OF A CONVEYOR 

* WHILE THE SECOND CONTROLS THE FLOW OF A LIQUID. 


* 
* 
* 
* 
* THE TASK OPERATES EACH 2@@ MSEC. k 
* * 
/ 


KEKKKKKK VERSION Le] KERR RRR KRK KKK KK EKKKEKKEKEEKKKKEKKEKE 


MAINSCONTROLSMODULE: DO; 


/* DECLARATION OF PID RECORD SET-UP TASK */ 
UQPSET: 
PROCEDURE (PRSPTR,ERRORSFLDSPTR,PRIVSPTR) EXTERNAL 


DECLARE (PRSPTR,ERRORSFLDSPTR,PRIVSPTR) ADDRESS; 
END UQPSET; 


/* DECLARATION OF PID CONTROL BITS */ 
UOPSCT: 
PROCEDURE (PRSPTR,CONTROLSPTR) EXTERNAL; 
DECLARE (PRSPTR,CONTROLSPTR) ADDRESS; 
END UQPSCT; 


/* PROCEDURE TO SET UP PID CONSTANTS */ 
UQPSCN: 
PROCEDURE (PRSPTR,CONSTANTSPTR) EXTERNAL; 
DECLARE (PRSPTR,CONSTANTSPTR) ADDRESS; 
END UQPSCN; 


/* DEFINE THE DEFAULT ERROR HANDLER */ 
UQPSBD: 
PROCEDURE (PRSPTR,BOUNDSPTR) EXTERNAL; 
DECLARE (PRSPTR,BOUNDSPTR) ADDRESS; 
END UOQPSBD; 


/* PROCEDURE TO CHANGE THE TIME INTERVAL #*/ 
UQPSTI: 
PROCEDURE (PRSPTR,TIMESINTERVALSPTR) EXTERNAL; 
DECLARE (PRSPTR,TIMESINTERVALSPTR) ADDRESS; 
END UQPSTI; | | 


/* DECLARATION OF THE PID CONTROL PROGRAM */ 
UQPPID: | SS : 
PROCEDURE (PRSPTR,IRSPTR) EXTERNAL; 
DECLARE (PRSPTR,IRSPTR) ADDRESS; 
END UQPPID; 
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ho RN 


NN 


/* 


fk 


/* 


/* 


/* 


/* 


/* 


/* 


/* 


DECLARATION OF WEIGHBELT ‘SPEED INTERFACE +f 
| WEIGHBELTSSPEED: 

PROCEDURE BYTE EXTERNAL; 

END WEIGHBELTSSPEED; 


‘DECLARATION OF WEIGHBELT WEIGHT INTERFACE * / 


WEIGHBELTSWEIGHT: 
PROCEDURE ADDRESS EXTERNAL; 
END WETGHRELTSWEIGHT;: 


DECLARATION OF LIQUID FLOW RATE ‘INTERFACE * / 
LIQUIDSFLOWSRATE: 
_ PROCEDURE ADDRESS EXTERNAL; 
END LIQUIDSFLOWSRATE ; 


DECLARATION OF WEIGHBELT MOTOR DRIVE INTERFACE 
WEIGHBELTSMOTORSDRIVE: 

PROCEDURE (SPEED) EXTERNAL; 

DECLARE SPEED. ADDRESS; 

END WEIGHBELTSMOTORSDRIVE; 


DECLARATION OF LIQUID VALVE INTERFACE */ 
LIQUIDSVALVESPOSITION: | 
PROCEDURE (POSITION) EXTERNAL; 
DECLARE POSITION BYTE; 
END LIQUIDSVALVESPOSITION; 


oe 


DECLARATION OF PROCESSOR @ INITIALIZATION MODULE a 


PROCESSORS@SINITIALIZATION: 
PROCEDURE EXTERNAL; 
oe HEROCES ORS SENT LAL TES ELON: 


DECLARATION OF PROCESSOR 1 INITIALIZATION MODULE */ 


PROCESSORSI1SINITIALIZATION:. 
PROCEDURE EXTERNAL; 
END’ PROCESSORSISINITIALIZATION; 


DECLARATION OF PROCESSOR 2 INITIALIZATION MODULE */ 


PROCESSORS2SINITIALIZATION: 
PROCEDURE EXTERNAL; 
END PROCESSORS2SINITIALIZATION; 


DECLARATION OF PIT COUNTER 1 INITIALIZATION */ 
COUNTERSI1SINITIALIZATION: 

PROCEDURE EXTERNAL; 

END COUNTERS 1$INITIALIZATION; 


DECLARATION OF PIT COUNTER 2 INITIALIZATION */ 
COUNTERS2SINITIALIZATION: 

PROCEDURE EXTERNAL; 

END COUNTERS2 INITIALIZATION j 
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mN EN pF 


NO hr RDN HOF 


ho ND Be N pk 


Nrmr Nrwpkr NN ED pF 


NO pk 


NOM BN pnp F 


/* 


/* 


ft 


/* 


/* 


/* 


/* 


/* 


DECLARATION OF FSP UNSIGNED LOAD PROCEDURES */ 
MQULD1: PROCEDURE. (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQULD1; 
MQULD2: PROCEDURE (IRSPTR, VALUESPTR) EXTERNAL; _ 


DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQULD2; 


DECLARATION OF FSP UNSIGNED MULTIPLY PROCEDURE */ 
MQUML1: PROCEDURE (IRS$PTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQUML1; | | 
MQUML2: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQUML2; 


DECLARATION OF FSP UNSIGNED DIVIDE PROCEDURE */ 

MQUDV1: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQUDV1; : 

MQUDV2: PROCEDURE (IRSPTR, VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR, VALUESPTR) ADDRESS; 3 
END MQUDV2; 


DECLARATION OF FSP SIGNED DIVIDE PROCEDURE */ 
MQSDV1: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQSDV1; | 
MOSDV2: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR, VALUED PART ADDRESS; 
END MQSDV2; 


DECLARTATION OF FSP SIGNED STORE PROCEDURE */ 
MQSST2: PROCEDURE (IRSPTR, VALUESPTR) alias 
DECLARE (IRSPTR, VERVE YE OR) ADDRESS 
END MQSST2; 


DECLARATION OF FSP SIGNED LOAD PROCEDURE */ 
MOSLD2: PROCEDURE: (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR, VALUESPTR) ADDRESS; 
END MQSLD2; 


DECLARATION OF FSP SIGNED SUBTRACT PROCEDURE */ 
MOSSB2: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR, VALUBSPER) ADDRESS; 
END MQSSB2; 


DECLARATION OF FSP UNSIGNED STORE PROCEDURE */ 
MQUST1: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR, VREVESEER) ADDRESS; 
END MQUST1; | 
MQUST2: PROCEDURE (IRSPTR, VALUESPTR) EXTERNAL; 
DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
END MQUST2; 
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82 
83 


126 


187 


oN pie. 


/* DECLARATION OF FSP SIGNED MULTIPLY PROCEDURE */ | 
| MQSML1: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
“DECLARE (IRS$PTR,VALUESPTR) ADDRESS; 


* 


_ END MQSML1; — 
SEJECT | 
ase [RRR REERERERER EERE EKER EREKEREKKERERERER 
DATA STORAGE AREAS FOR THE PID CONTROL * 


KEKKKKEKKEKEREKEE ERE RE RREREREERKAEKERKKRRERREKEEEE / 


/* DEFINITION OF LIMITATION CONSTANTS */ 


/* 


/* 


y* 


/* 


[* 


/* 


DECLARE 


RESERVE 


DECLARE 


DECLARE 


RESERVE 
DECLARE 


RESERVE 
DECLARE 


DECLARE MAXSMOTORSSPEED LITERALLY '55@'; 
DECLARE MINSMOTORSSPEED LITERALLY '@'; 
DECLARE MAXS$VALVES$MOVEMENT LITERALLY '1@'; 
DECLARE MINSVALVESMOVEMENT LITERALLY '-1@'; 
DEFINITION OF PID PARAMETER COEFFICIENTS */ 
DECLARE FEEDERSC®@ LITERALLY 'l1'; 
DECLARE FEEDERSC1 LITERALLY 'l'; 
DECLARE FEEDERSC2 LITERALLY 'l'; 
DECLARE FEEDERSC3 LITERALLY '1l'; 
DECLARE FEEDERSTIMESINTERVAL LITERALLY '1l'; 
DECLARE FEEDERSSCALESFACTOR LITERALLY '1l'; 
DECLARE LIQUIDSC®@ LITERALLY '1l'; 
DECLARE LIQUIDSC] LITERALLY 'l'; 
DECLARE LIQUIDSC2 LITERALLY '1'; 
DECLARE LIQUIDSC3 LITERALLY '‘'1l'; 
DECLARE LIQUIDSTIMESINTERVAL LITERALLY '1l'; 
DECLARE LIQUIDSSCALESFACTOR LITERALLY '1@'; 
DEFINITION OF RESET LATCH PARAMETERS */ . 
DECLARE RESETSLATCHSADR LITERALLY '@EAH'; 
DECLARE INDICATORSON LITERALLY '@7H'; 
DECLARE INDICATORSOFF LITERALLY '@FH'; 
RESERVE 18 BYTES FOR THE INTEGER RECORD */ 


IR (18) BYTE PUBLIC; 


42 BYTES FOR EACH PID RECORD */ 
PRCV (42) BYTE; 
PRLQ (42) BYTE; 


SPACE FOR COUNTER DATA */ 
(LIQSCOUNT,BELTSCOUNT) BYTE PUBLIC; 


12 BYTES FOR EACH CONSTANT ARRAY */ 
CONSTANTS] STRUCTURE ( 


ADDRESS, 


ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS, 
ADDRESS ); | 
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188 


109 


110 


lil 
112 


113 


114 


ime Gs 


116 


dae 


118 


119 


122 


12] 


122 


fs 


/* 


i 


/* 


/* 


/* 


/* 


fk 


/* 


/* 


/* 


DECLARE CONSTANTS2 STRUCTURE ( 
C@ ADDRESS, 
Cl ADDRESS, 
C2 ADDRESS, 
C3 ADDRESS, 
DT ADDRESS, 
S ADDRESS ); 


RESERVE 8 BYTES FOR EACH BOUNDS ARRAY */ 
DECLARE BOUNDS] (4) ADDRESS DATA ( 
OOOH, 
OOOH, 
MAXSMOTORSSPEED, 
MINSMOTORSSPEED ); 
DECLARE BOUNDS2 (4) ADDRESS DATA ( 
GUD, 
GOOD, 
MAXSVALVESMOVEMENT, 
MINSVALVESMOVEMENT ); 


RESERVE 1 BYTE FOR BACH CONTROL BYTE */ 
DECLARE CONTROL] BYTE DATA (@73H) ; 
DECLARE CONTROL2 BYTE DATA (@53H); 


DECLARE TIME INTERVAL */ 
DECLARE TIMESINTERVAL ADDRESS DATA (1); 


RESERVE SPACE FOR THE CURRENT BELT SPEED */ 
DECLARE BELTSSPEED BYTE; 


RESERVE SPACE FOR THE CURRENT BELT WEIGHT */ 
DECLARE BELTSWEIGHT ADDRESS; 


RESERVE SPACE FOR THE LIQUID FLOW */ 
DECLARE LIQUIDSFLOW ADDRESS; 


RESERVE SPACE FOR THE EFFECTIVE SETPOINT */ 
DECLARE MASSSSETPOINT ADDRESS; 


RESERVE SPACE FOR THE DESIRED SETPOINT */ 
DECLARE SETSPOINT ADDRESS; 


RESERVE SPACE FOR THE DISTANCE OF BELT PER REVOLUTION 
DECLARE DISTSREV BYTE DATA (1860); 


DEFINE THE CONVEYOR LENGTH */ 
DECLARE CONVSLENGTH BYTE DATA (2@@); 


DEFINE THE CONSTANT SIX */ 
DECLARE SIX BYTE DATA (6); 


RESERVE STORAGE FOR ACTUAL CURRENT MASS FLOW */ 
DECLARE MASSSFLOW ADDRESS; 
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/* 


/* 


/* 


/* 


/* 


RESERVE 
DECLARE 


RESERVE 
DECLARE 


RESERVE 


DECLARE 


RESERVE 
DECLARE 


RESERVE 
DECLARE 
DECLARE 


SPACE FOR. BELT CONTROL OUTPUT */ 
BELTSCONTROL ADDRESS; 

SPACE FOR LIQUID RATIO */ 
LIQUIDSRATIO BYTE; 


SPACE FOR LIQUID CONTROL OUTPUT */ 
LIQUIDSVALVE ADDRESS; 


SPACE FOR RUN/HALT CONTROL */ 
SYSTEMSRUNNING BYTE PUBLIC; _ 


SPACE FOR ERROR FIELD */ 


ERRORSFIELD ADDRESS DATA (@F8@@H) ; 
DUMMY ADDRESS; | : 


/* RESERVE SPACE FOR PIC ICW BYTE */ 
_ DECLARE 


ICW BYTE; 


ys DEFINE CONSTANT 16@¢@ ey 


DECLARE 


THOUSAND ADDRESS DATA (1902); 


_/* DEFINE CONSTANT @ */— 


DECLARE 


ZERO: ADDRESS DATA (8); 


/* DEFINE INTERRUPT JUMP TABLE */: 


DECLARE JUMP$STABLE BYTE AT (3F@0H); 

/* DECLARATION OF PIC ADDRESSES ON ISBC 569 BOARD */ 
DECLARE PICSICW1$PTR © LITERALLY '@ECH'; : 
DECLARE PICSICW2$PTR LITERALLY '@EDH'; 
DECLARE PICSINTSMASKSPTR LITERALLY '®EDH'; 

/* DECLARATION OF PIC CONSTANTS */ | 
DECLARE CLRSLOWSBITS = LITERALLY '@E@H'; 
DECLARE INTERVAL$4 © LITERALLY '@16H'; 
DECLARE INTERRUPTSMASK LITERALLY 'OF4H'; 


S$EJECT 


Vata 1 SuRUARINES TEARaAN He wane dete ee sans 


* INITIALIZE PROGRAM AT START-UP OF SYSTEM * 


* THIS PROCEDURE IS CALLED AT START-UP * 
Ree RISER ERT TAPCO PERC Ree UES a OS Fd 


INITIATION: 


PROCEDURE PUBLIC; 


/* DISABLE THE INTERRUPTS */ 


DISABLE; 


/* INITIALIZE PID RECORD */ 
CALL UQPSET (. PRCV, . ERRORSFIELD, .DUMMY) ; 
CALL UQPSET (.PRLQ,.ERRORSFIELD, .DUMMY) ; 
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145 
146 
147 
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149 
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151 
152 
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155 
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157 


158 
159 


15@ 
161 


162 
163 


164 
165 


166 


167 


168 


169 


176 


171 


172 


no NM po ND po NH 


bo N po ND po NY 


NO po 


nm N NO po Nm N we. 


NO 


/* INITIALIZE THE CONTROL BITS */ 
CALL UQPSCT (.PRCV,.CONTROL1) ; 
CALL UQPSCT (.PRLQ,.CONTROL2) ; 


/* 


{* 


/* 


Yas 


/* 


fk 


/* 
ye 


/* 


yt 


SET UP THE PID CONSTANTS */ 


CONSTANTS 1.C@ 
CONSTANTS] .Cl 
CONSTANTS1.C2 
CONSTANTS] .C3 
CONSTANTS1.DT 
CONSTANTS].5 


CONSTANTS2.C@ 
CONSTANTS2.Cl 
CONSTANTS 2.C2 
CONSTANTS2.C3 
CONSTANTS 2.DT 
CONSTANTS2.S 


CLEAR SETPOINTS 


SETPOINT = @; 


LIQUIDSRATIO = 
SYSTEMSRUNNING 


Q; 


FEEDERSCQ; 
FEEDERSC1; 
FEEDERSC2;. 
FEEDERSC3; 
FEEDERSTIMESINTERVAL ; 
FEEDERSSCALESFACTOR; 


LIQUIDSCQ; 
LIQUIDSC]; 
LIQUIDSC2; 


LIQUIDSC3; 


LIQUIDSTIMESINTERVAL; 
LIQUIDSSCALESFACTOR; 


a7 


O; 


INITIALIZE THE CONSTANTS */ 
CALL UQPSCN (.PRCV,.CONSTANTS1); 
CALL UQPSCN (.PRLQ,.CONSTANTS2) ; 


INITIALIZE THE BOUNDS */ 
CALL UQPSBD (.PRCV,.BOUNDS1); 


CALL UQPSBD (.PRLQ,.BOUNDS2) ; 


SET THE TIME INTERVAL */ 
CALL UQPSTI (.PRCV,.TIMESINTERVAL) ; 
CALL UQPSTI (.PRLQ,.TIMESINTERVAL) ; 


INITIALIZE PROCESSOR @ */ 
CALL PROCESSORS@SINITIALIZATION; 


INITIALIZE PROCESSOR 1 */ 
CALL PROCESSORSISINITIALIZATION; 
INITIALIZE PROCESSOR 2 */ 
CALL PROCESSORS2SINITIALIZATION; 


INITIALIZE. COUNTER 1 */ 
CALL COUNTERSISINITIALIZATION; 


INITIALIZE COUNTER 2 */ 
CALL COUNTERS2$INITIALIZATION; 


INITIALIZE INTERRUPT CONTROLLER */ 
ICW = (LOW (.JUMPSTABLE) AND 
CLRSLOWSBITS ) OR 


INTERVALS4 


OUTPUT. (PICSICW1SPTR) = ICW; 
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bis 2 ICW = HIGH (.JUMPSTABLE) ; 


174 2 OUTPUT (PICSICW2SPTR) = ICW; 

/* SET INTERRUPT MASKS */ 
i an OUTPUT (PECSINTSMASKSPTR) _ = INTERRUPTSMASK; 

/* ENABLE INTERRUPTS a | 
176 2 ENABLE; 

| /* RETURN | TO MAIN PROGRAM an 
177. 2 RETURN; 
178 2 _ END INITIATION; 
SEJECT. | 


UOC ISO GI ISSO ISU ICI IIS IOI IOS TOPIC ITI Ik , 


* THIS IS THE PID CONTROL ROUTINE. IT IS ENTERED * 
* EACH 208 MILLISECONDS THROUGH AN INTERRUPT GEN- * 
* ERATED BY THE FREQUENCY COUNTER UPI AND SENT TO * 


* INTERRUPT 3. * 
KKK KKK KKK ERE RE RRR RRR KKK EKER RRR RRR ER ERE KKRKEKRERER / 


179 1 PIDRUN: PROCEDURE INTERRUPT 3 PUBLIC; 


/* TURN THE LED INDICATOR ON */ 
189 2 - OUTPUT (RESETSLATCHSADR) = INDICATORSON; 
/* GET WEIGHBELT WEIGHT */ 
181 2 BELTSWEIGHT=WEIGHBELTSWEIGHT; 
/* GET LIQUID FLOW RATE */ 
182 2 LIQUIDSFLOW=LIQUIDSFLOWSRATE; 
/* CONTROL START-STOP RAMP */ 
183 2 oe IF SYSTEMSRUNNING 
THEN MASSSSETPOINT=SETPOINT; 
185 2 ELSE MASSSSETPOINT= Bh; 


/* DETERMINE ACTUAL MASS FLOW ON WEIGHBELT */ 


186 2 CALL MQULD2(.IR,.BELTSCONTROL) ; 
187 2 CALL MOQUML2(.IR,.BELTSWEIGHT); 
188 2 CALL MQUML1(.IR,.DISTSREV) ; 
189 2 ‘CALL MQUDV1(.IR,.CONVSLENGTH) ; 
198 «2 CALL MOSDV2(.IR,.THOUSAND) ; 
191 2 CALL MOSST2(.IR,-.MASSSFLOW) ; 

/* COMPUTE ERROR SIGNAL ON WEIGHBELT */ 
192 2 CALL MOSLD2(.IR,.«MASSS$SETPOINT); 
193 2 CALL MQSSB2(.IR,.MASSSFLOW) ; 

/* HANDLE PID BELT CONTROL ALGORITHM */ 
194 2 CALL UQPPID(.PRCV,.IR); 

/* STORE OUTPUT SIGNAL */ 
195 2 CALL MOQUST2(.IR,.BELTSCONTROL) ; 
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196 
197 
198 


199 


261 


282 


203 


204 


205 


206 


207 


208 
209 
210 


/* 


COMPUTE LIQUID SETPOINT */ 
CALL MQSLD2(.IR,.MASSSFLOW) ; 
CALL MOQSML1(.IR,.LIQUIDSRATIO); 
CALL MQSML1(.IR,.SIX); 


VERIFY THAT WEIGHBELT IS MOVING */ 
IF WEIGHBELTSSPEED = @ 
THEN CALL MQULD2(.IR,.ZERO); 


COMPUTE LIQUID ERROR */ 
CALL MOSSB2(.IR,.LIQUIDS$FLOW) ; 


HANDLE PID LIQUID CONTROL */ 
CALL UQPPID(.PRLQ,.IR); 
STORE OUTPUT SIGNAL */ 
CALL MQUST1(.IR,.LIQUIDSVALVE) ; 


OUTPUT WEIGHBELT CONTROL SIGNAL */ 


CALL WEIGHBELTSMOTORSDRIVE (BELTSCONTROL) ; 


OUTPUT FLOW CONTROL SIGNAL */ 


CALL LIQUIDSVALVESPOSITION (LIQUIDSVALVE) ; 


SEND END OF INTERRUPT TO 8259 CONTROLLER */ 


OUTPUT (@ECH) =@20H; 


TURN THE LED INDICATOR OFF */ 


OUTPUT (RESETSLATCHSADR) = INDICATORSOFF; 


RETURN FROM CONTROL TASK */ 
RETURN; 
END PIDRUN; 


2 
2 
2 

/* 
2 

/* 
2 

/* 
2 

/* 
2 

/* 
2 

/* 
2 

Vis 
2 

/* 
2 

a 
2 
2 
1 END; 


MODULE INFORMATION: 


CODE AREA SIZE 
VARIABLE AREA SIZE. 
MAXIMUM STACK SIZE 


= fZ1C1H 449D 
= $0948 148D 
= O@0AH 18D 


465 LINES READ 
4) PROGRAM ERROR (S) 


END OF PL/M-8@ COMPILATION 


3-107 


AFN-01931A 


ISIS-II PL/M-8@ V3.1 COMPILATION OF yOPEEe PROCESO ORIENT TIAL ee TA ONnOnUES 

OBJECT MODULE PLACED IN :F1:SBC941.0Bd © 

COMPILER INVOKED BY: . PLM8@ :F1:SBC9411. PLM DEBUG. PAGEWIDTH (72) Saree PR 
- -OCESSOR INE TIALLZATION® i 


OIG S EI IO SSSI IIS GIT IO EI IOS III IIS I IIE 
* THIS PROGRAM IS USED TO INITIALIZE THE ISBC * 


* 941 PROCESSOR INSTALLED IN SOCKET @. THE * 
* DEVICE WILL OPERATE | IN ane FREQUENCY OUTPUT * 
* MODE. = * 


IEEE IS ISIE ISIS I II III ITI ATI AT REIS / 
1 PROCESSORSINITIALIZATIONSMODULE: DO; 


/* DECLARATION OF ADDRESSES */ aa 
DECLARE UPIS@$STATUS LITERALLY '@E5H'; 


2 1 

3. F DECLARE UPIS@SCOMMAND LITERALLY 'GE5H'; 
4 1 DECLARE UPIS@$DATA = LITERALLY "QE4H'; 
5 1 DECLARE UPI$1$STATUS LITERALLY '@E7H'; 
6 1 _ DECLARE UPIS$1S$COMMAND LITERALLY '@E7H'; 
7 1 DECLARE UPIS1SDATA LITERALLY '@EGH'; 
8 il DECLARE UPIS2$STATUS LITERALLY '@SE9H'; 
9 1 DECLARE UPIS2S$COMMAND- LITERALLY '@E9H'; 


DECLARE UPIS2$DATA LITERALLY 'GE8H' 


-7* DECLARATION OF ISBC 941 COMMANDS */ 


11 1 DECLARE SETP1 | LITERALLY '@@BH'; 
12 ~-1 DECLARE CLRP1l - LITERALLY '@@DH'; 
13 1 DECLARE CLRP2 LITERALLY '@@EH'; 
14 1 DECLARE PAUSE LITERALLY '@@5H'; 
15. 1 DECLARE LOOP LITERALLY '@@4H'; 
16 i DECLARE INITPF LITERALLY '€@2H'; 
17 1 DECLARE PACIFY LITERALLY '@@1H'; 
18 1 DECLARE ENFLAG LITERALLY '@O@6H'; 


/* DECLARATION OF ISBC 941 STATUS BITS */ 


19 1 DECLARE RFC LITERALLY '@8@H'; 
20 1 DECLARE IBF aN LITERALLY '@@2H'; 
21 1 DECLARE QF LITERALLY '@10H'; 
/* DECLARATION OF ISBC 941 #@ INITIALIZATION DATA */ 
22 1 DECLARE FREQ LITERALLY '@B5H'; 
23 1 DECLARE SF LITERALLY 'O@@H'; 
24 1 DECLARE OUTPUTSENABLE@ LITERALLY '@@1H'; 
25 1 DECLARE INITIALSSTATE LITERALLY '@@@H'; 
26 1 DECLARE DELAY LITERALLY '@@1H'; 
27 1 DECLARE PERIOD LITERALLY '@@@H'; 
28 1 DECLARE INITIALSOUTPUT LITERALLY '@@EH'; 
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29 
30 
cel 


32 


oS 


34 


35 


a ee 


Ww Wd No w Wwe Wp to N 


No wnN > 


/* DECLARATION OF INTERVAL TIMER PARAMETERS */ 


‘DECLARE PITS@SMODE .° LITERALLY '@16H'; 
DECLARE PITS@SINTERVAL LITERALLY ‘@#EH'; 
DECLARE PITS@#SMODESWRD LITERALLY '@E3H'; 


DECLARE PITS@SCOUNT LITERALLY '@E@H'; 


/* DECLARATION OF COUNTER LOCATIONS */ 
DECLARE (LIQSCOUNT, BELTSCOUNT) BYTE EXTERNAL; 


/* DECLARATION OF ISBC 941 PRIMARY DATA */ 
DECLARE INITS$OS$TABLE(6) BYTE DATA ( 
FREQ, 
SF, 
OUTPUTSENABLE®, 
INITIALSSTATE, 
DELAY, 
PERIOD); 


/* DECLARATION OF MISC PARAMETERS */ 
DECLARE I BYTE; 


J BRR ERKRRERERKEKEE KER EKER REKKEEKEKEKREKERKEKEKKEKK KK 


INITIALIZATION PROGRAM BODY . 
Pea mre eee gl rag Rete eae Rene 


PROCESSORS@SINITIALIZATION: PROCEDURE PUBLIC; 


/* INITIALIZE COUNTER @ FOR 18 MICROSECONDS */ 
OUTPUT (PITS# SMODESWRD) =PITS@SMODE; 
- OUTPUT (PITSOSCOUNT) =PITS@SINTERVAL; 


/* VERIFY THAT PROCESSOR IS. RESET */ 
DO WHILE ((INPUT(UPIS@SSTATUS) AND RFC) = @); | 
DO WHILE ((INPUT(UPIS@SSTATUS) AND IBF) <> @); 
END; 
OUTPUT (UPIS@SCOMMAND ) =PACIFY; 
END; | | con 


/* REQUEST PRIMARY FUNCTION */ 
DO WHILE pe PEE PEG eee AND IBF) <> @); 
END; 
OUTPUT (UPI $@$COMMAND) = INITPF; 


/* LOAD INITIAL PARAMETERS */ 
DO: T=0-TO Spa. | 
DO WHILE ((INPUT(UPIS@SSTATUS) AND IBF) <> @); 
END; | 
-. OUTPUT (UPIS@SDATA)=INITS@STABLE (1); 
END; 


/* TERMINATE PARAMETER LOADING */ 


DO WHILE ((INPUT(UPIS@$STATUS) AND IBF) <> @); 
END; : 
OUTPUT (UPI$@SCOMMAND) = PAUSE; 
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76 © 


71 


NW po 


Now 


meee pe Pe 


Ww & W Dy 


/* START FREQUENCY FUNCTION */ — 


DO WHILE UNED EU eee e ante AND IBF) <>2); 
END; |. . 
_ OUTPUT (UPISSCOMMAND = LOOP; 


yt SET UNUSED BITS TO ALLOW EXPANSION * / 


DO WHILE ( (INPUT (UPISBSSTATUS) AND IBF) <> @); 


END; 
OUTPUT (UPIS@SCOMMAND )=CLRP2; 


DO WHILE ((INPUT(UPI$@SSTATUS) AND IBF) <> @); 


END; 
OUTPUT (UPI S@SDATA) = INITIALSOUTPUT; 


/* RETURN TO CALLING PROGRAM kf 
RETURN ; 


END PROCESSORS@SINITIALIZATION; 
SEJECT 
AU UUTECETCTTCTCTCCTTTCT TCT CTECOOTCeTeeeeeeee ere: 


* THIS PROCEDURE IS USED TO INITIALIZE THE ISBC * 
* 94] PROCESSOR INSTALLED IN SOCKET 1. THE DE- * 


.* VICE WILL OPERATE IN -THE. FCOUNT, HIGH FRE- * 


* QUENCY INPUT MODE. * 


RRR KEKE RK ERE EKER EKER EERE EKER REKEEKREREKEKREKEKEKKEKK / 


ys DEFINE INITIALIZATION. PARAMETERS */ 


DECLARE FCOUNT LITERALLY '633H'; 
DECLARE INPUTSSELECT LITERALLY '@@1H'; 
DECLARE OUTPUTSENABLES1 LITERALLY '@@1H'; 
DECLARE SAMPLINGSINTERVAL LITERALLY '@@9H'; 
DECLARE INITIALSSTATES1 _ LITERALLY Ee 


/* DECLARE PARAMETER INITIALIZATION TABLE */ 
DECLARE INITSISTABLE(4) BYTE DATA ( 
FCOUNT, 
INPUTSSELECT, 
OUTPUTSENABLES1, | 
SAMPLINGSINTERVAL _ ); 


[J BRRRRRKEKER ERE REREK ERE REE RKEREREREKRREKEREREREKEKRE 


* INITIALIZATION BODY - 
HK KKK KERRIER RR EKER IER RRR REE KEKE RE RE RRR ERERE / 


~PROCESSORSISINITIALIZATION: PROCEDURE PUBLIC; 


/* VERIFY THAT PROCESSOR IS RESET / 
DO WHILE ((INPUT(UPISI1SSTATUS) AND RFC) = @Q@); 


‘ 


v 


DO WHILE Ee sane ore) AND IBF) <> 9); 


END; 
OUTPUT (UPI $1 $COMMAND)= PACIFY; 
END; 
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ee 


Ny WpDhD Wa) ho GW NO Ww © Ww AO NOWDHD . 


NOW po 


/* 


/* 


/* 


/* 


/* 


/* 


REQUEST PRIMARY FUNCTION */ 

DO WHILE ((INPUT(UPISISSTATUS) AND IBF) <> @); 
END; . 

OUTPUT (UPIS1SCOMMAND)=INITPF; 


LOAD INITIAL PARAMETERS */ 

DO I=¢ TO 3; 
DO WHILE ((INPUT(UPIS1SSTATUS) AND IBF) <> 
END; 
OUTPUT (UPISISDATA)=INITSI1STABLE (I); 

END; 


TERMINATE PARAMETER LOADING */ 

DO WHILE ((INPUT(UPIS1SSTATUS) AND IBF) <> @); 
END; 

OUTPUT (UPI$1SCOMMAND)=PAUSE; 


SET UNUSED BITS HIGH FOR SPARE ENABLES */ 

DO WHILE ((INPUT(UPISISSTATUS) AND IBF) <> @); 
END ; i 

OUTPUT (UPIS1SCOMMAND) =SETP1; 

DO WHILE ((INPUT(UPIS1SSTATUS) AND IBF) <> @); 
END; 

OUTPUT (UPISI1SDATA) =INITIALSSTATES1; 


START FREQUENCY COUNT OPERATION */ — 
DO WHILE ((INPUT(UPISISSTATUS) AND IBF) <> @); 
END; , 
OUTPUT (UPIS1SCOMMAND)=LOOP; 


RETURN TO CALLING PROGRAM */ 
RETURN ; 


END PROCESSORSISINITIALIZATION; 


SEJECT 

J BRE REREREKEREREKERERKEKEKEREKKERERKERERKEKRKEKKEEKKEKRKEES 
* THIS PROCEDURE IS USED TO INITIALIZE THE ISBC * 
* 941 INSTALLED IN SOCKET 2. THE DEVICE WILL BE * 


* OPERATED AS A STEPPER MOTOR DRIVER. " 
KKK KKK KEKE ERK KERR RRR AEKRERRKE AER ER EKER KERR ERE EER / 


/* DEFINE INITIALIZATION PARAMETERS */ 


DECLARE STEPPER LITERALLY '@17H'; 
DECLARE SCALESFACTOR | LITERALLY '@DFH'; 
DECLARE OUTPUTSENABLE$2 LITERALLY '@F@H'; 
DECLARE OUTPUTSPOLARITY LITERALLY '@5@H'; 
DECLARE COMMONSPERIOD LITERALLY '@@4H'; 
DECLARE P2@STRANI1 LITERALLY '@O@@H'; 
DECLARE P2@STRAN2 LITERALLY '@O@H'; 
DECLARE P21STRAN1 LITERALLY '@O@@H'; 
DECLARE P21STRAN2 LITERALLY '@@GH'; 
DECLARE P22STRANI LITERALLY '@@@H'; 
DECLARE P22STRAN2 LITERALLY '@@@H'; 
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126 
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mwWwN | 


DECLARE 


DECLARE. 


DECLARE 


DECLARE 
DECLARE 


DECLARE 
DECLARE 


DECLARE. 
DECLARE 


P23STRAN1. 


P238TRAN2. | 


P24STRAN1 


P24STRAN2.... 
P25STRAN] 
P25STRAN2,._. 
P26STRANI] _ 


P26STRAN2. 


P27STRANI 


DECLARE 


DECLARE 


P27STRAN2 ~~ 


CLRSLOWSPORT 


LITERALLY 
_. LITERALLY 


LITERALLY 


LITERALLY 
LITERALLY 
LITERALLY 
LITERALLY 
_ LITERALLY 
_.. LITERALLY 
ica eneete 


LITERALLY 


_/* DECLARE rien tree Ree 


DECLARE , INITS2STABLE (21) BYTE DATA ( 


* 


STEPPER, 


SCALESFACTOR, _ 


OUTPUTSENABLES2,. 
OUTPUTSPOLARITY, 


COMMONSPERIOD, 


P2@STRAN1, __ 
~P28STRAN2, | 
P21STRAN1,~ 
P21STRAN2, | 
P22STRAN1,. . 
P22STRAN2, 


P23STRAN1, 


P23STRAN2,. 


P24STRANI1, 


P24STRAN2, 


P25STRAN1, 


P25STRAN2, 
P26STRANI, 
P26STRAN2, 
P27STRAN1, 
P27STRAN2 - 


_ Se eine, 9 
[iy RACE Tae aa Waa LER dG ANWR EW aGs CARRERE TAROT ER 
* 


INITIALIZATION BODY 


PROCESS Ot 722 NTTISCIZATION: 


as VERIFY THAT PROCESSOR Is RESET ay. 


DO WHILE ( (INPUT (UPIS2SSTATUS) -AND RFC) 
2 oe as DO) WHILE 
‘END; 
_ OUTPUT (UPI$2$COMMAND) = =PACIFY; 
Rae ets 


FP. REQUEST PRIMARY FUNCTION. 4p 


*/, 


ae kaha se aa cl as ee ele 


Paeee Une, PUBREC? 


=O); 
( (INPUT (UPI$2$STATUS) AND Eero. <> 0); 


DO WHILE ( (INPUT (UPIS2SSTATUS ) AND IBF) <> B); 


END; 


OUTPUT (UPI$2S$COMMAND)= INITPF; 
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/* LOAD INITIAL PARAMETERS Fe 


132 2 DO I=@ TO 20; | ; 
133 3 DO WHILE ( (INPUT (UPTS2$STATUS) AND IBF) <> @); 
134 4 END; | 
135 3 OUTPUT (UPIS2SDATA) = INITS2STABLE (I); 
136 3 END; | 

/* TERMINATE PARAMETER LOADING */_ 
137 2 DO WHILE ( (INPUT (UPIS2SSTATUS ) AND IBF) <> @); 
138 3 END; 
139 2 OUTPUT (UPI$2$COMMAND)=PAUSE; 

/* START STEPPER CONTROLLER OPERATION */ 
14@ 2 DO WHILE ((INPUT(UPIS2SSTATUS) AND IBF) <> @); 
141 3 END; 
142 2 OUTPUT (UPIS2SCOMMAND)=LOOP; 

/* SET UNUSED BITS LOW TO ENABLE GENERAL FUNCTIONS */ 
143 2 DO WHILE ((INPUT(UPIS2SSTATUS) AND IBF) <> @); 
144 3 END; | » 
145 2 OUTPUT (UPI$2$COMMAND) = CLRP1; , 
146 2 DO WHILE ( (INPUT (UPIS2$STATUS) AND IBF) <> B); 
147 3 END; 
148 2 OUTPUT (UPI$2SDATA) =CLRSLOWSPORT; 

/* RETURN TO CALLING PROGRAM */ 
149 2 RETURN ; 
15@ 2 END PROCESSORS2SINITIALIZATION; 

SEJECT 

J RRREREKRERER ERE REE RE RRR KERR KEKRKEKEKEKREKEKEKEKEKRKEREREKE 

* THIS PROCEDURE IS USED TO INITIALIZE COUNTER * 

* 1 TO PERFORM AS AN EIGHT BIT BINARY COUNTER * 

* WHICH WILL BE USED TO MEASURE THE BELT SPEED.* 

KRKKEKKEK KEKE EKER EK KEKE KEK KKKEKEEKREKERERERKEEKEREKEE / 
151 l COUNTERSISINITIALIZATION: PROCEDURE PUBLIC; 

/* INITIALIZE COUNTER 1 FOR EIGHT BIT COUNTING */ 
152 2 LIQSCOUNT = @; 

/* RETURN TO CALLING PROGRAM */ 
153 2 RETURN; 
154 2 END COUNTERSLSINITIALIZATION; 


SEJECT 

[J RRREKRERERE RRR KEK RK EKER KRKEKEREREKEKERKEKREKRERERERERES 
* THIS PROCEDURE IS USED TO INITIALIZE COUNTER * 
* 2 TO PERFORM AS AN EIGHT BIT BINARY COUNTER * 
* WHICH WILL BE USED TO MEASURE THE LIQUID * 


* FLOW THROUGH THE METER. * 
KEKE KKK KIRK RAK KEK KKK KERR HERE R RRR REREREREEREEE / 
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155 
156 
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158 
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COUNTERS2SINITIALIZATION: PROCEDURE PUBLIC; 


pe INITIALIZE COUNTER 2 FOR EIGHT BIT COUNT ING * /. 


BELTSCOUNT = @ ; 


/* RETURN TO CALLING PRCOhan a 
RETURN; Ss | 


END salle eat 


END PROCESSORSINITIALIZATIONSMODULE; 
SEJECT 


MODULE INFORMATION: 


‘CODE AREA SIZE 
VARIABLE AREA SIZE. 
MAXIMUM STACK SIZE 
329 LINES READ 

~@ PROGRAM ERROR(S) 


= @201H 513D 
= Q@01H 1D 


COORH @D 


END OF PL/M-8@ COMPILATION 
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ISIS-II PL/M-8@ V3.1 COMPILATION OF MODULE PROCESSORINTERFACEMODULE 
OBJECT MODULE PLACED IN :F1:OPR941.0OBJ 
COMPILER INVOKED BY: PLM8@ :F1:OPR941.PLM DEBUG 


SINTVECTOR (4, 3F@QH) 

$PAGEWIDTH (72) 

STITLE ('PROCESSOR INTERFACE') 

[RRR KEKE KK EER KERR EKER REE ERK KER KEKE EK KEKEKERERES 


* THESE PROGRAMS PROVIDE THE OPERATING INTER- * 


* FACE BETWEEN THE APPLICATION PROGRAM AND * 
* THE ISBC 941 PROCESSORS OR COUNTERS. * 
KHKKKKKEKEKEKKEKEERKE KEKE EERE KR REERERKRE RE REREREKREKE / 
; PROCESSORSINTERFACESMODULE: DO; 
/* DECLARATION OF ADDRESSES */ 
2 4. DECLARE UPIS@SSTATUS LITERALLY 'GES5H'; 
3 1 DECLARE UPIS@SCOMMAND LITERALLY '@E5H'; 
4 1 DECLARE UPIS@SDATA. LITERALLY '@E4H'; 
5 1 -- DECLARE UPISI1S$STATUS LITERALLY '@E7H'; 
6 1 DECLARE UPISIS$COMMAND LITERALLY '@E7H'; 
7 1 DECLARE UPIS1S$DATA LITERALLY 'E6H'; 
8 1 DECLARE UPIS2$STATUS LITERALLY '@ES9H'; 
9 |] DECLARE UPIS2SCOMMAND LITERALLY '@E9H'; 
1891 DECLARE UPIS$2SDATA LITERALLY 'SE8H'; 


/* DECLARATION OF ISBC 941 COMMANDS */ 


11 1 DECLARE SETP1 LITERALLY '@@BH'; 
12 1 DECLARE CLRP1 LITERALLY '@@DH'; 
13 ik DECLARE CLRP2 LITERALLY '®Q@EH'; 
14 1 DECLARE RDFC® LITERALLY '@42H'; 
LS 1 DECLARE RDFCt LITERALLY '@43H'; 
16 1 DECLARE PAUSE LITERALLY '@@5H'; 
ay 1 DECLARE LOOP LITERALLY '@@4H'; 
18 1 DECLARE INITPF LITERALLY '@@2H'; 
19 lL DECLARE PACIFY LITERALLY '@@1H'; 
20 1 DECLARE ENFLAG LITERALLY '@O@6H'; 
21 1 DECLARE SETOE LITERALLY '@71H'; 


/* DECLARATION OF ISBC 941 STATUS BITS */ 
DECLARE RFC LITERALLY '@8@H'; 


1 ; 
23. 1 DECLARE IBF LITERALLY '@@2H'; 
24 1 DECLARE OBF - LITERALLY '@@1H'; 
25 1 DECLARE QF | LITERALLY ‘@l1@H'; 
26 1 DECLARE QNE © LITERALLY '@2@6H'; 

/* DEFINE THE MATH ROUTINES USED BY MODULES */ 

27 HE MQULD4: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
28 2 DECLARE (IRSPTR, VALUESPTR) ADDRESS; 
29 2 END MQULD4; 
3@ 1 _MQUDV2: PROCEDURE (IRSPTR,VALUESPTR) EXTERNAL; 
Sl 2 DECLARE (IRSPTR,VALUESPTR) ADDRESS; 
32 2 END MQUDV2; 
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. | MQUDV1: PROCEDURE (IRSPTR, ‘VALUESPTR) EXTERNAL; a pes 
DECLARE (IRSPTR, VALUESPTR) ADDRESS; = os 
END ‘MQUDV1; ~— iE 
MQUST1: PROCEDURE (IRSPTR, VALUESPTR) | EXTERNAL; 
DECLARE (IRSPTR, VALUESPTR) ADDRESS; 
END mOuoL a? 


oe /* ‘DEFINE, THE MATH ACCUMULATOR STORAGE ‘AREA * / 


DECLARE IR(18) © BYTE EXTERNAL; 


ff. DEFINE THE COUNTER LOCATIONS */ 


DECLARE (LIQSCOUNT, BELT SCOUNT) BYTE EXTERNAL; 


SEJECT ea . : = 
ECS GSO GIGS IGE IGOISSTII SEG GIGI IOI IIR Tk 


_* THIS PROGRAM IS USED TO GENERATE A FREQUENCY * 


* OUTPUT USING THE ISBC 941 MODULE INSTALLED IN * 
* SOCKET NUMBER @. TO PROVIDE MAXIMUM RESOLU- * 
* TION, FOUR PERIODS WILL BE USED. THE FREQUEN-* 
* CY RANGES CORRESPONDING TO EACH PERIOD ARE: #* 
ek - RANGE FREQ © RESOLUTION * 
* oo. 50 T0 165 HZ 2 HZ * 
eee Fe ee 166 TO 225 HZ 3°HZ * 
* 3 226 TO 285 HZ 3 HZ * 
ee 4 286 TO 550 HZ 6 HZ * 
* THE SCALE FACTOR IS COMPUTED BY THE FORMULA: * 
* SF=100000/((FREQ)*(RANGE FACTOR) ) * 
A A i all 


_WEIGHBELT$MOTORSDRIVE: PROCEDURE (FREQ) PUBLIC; 


ce DECLARATION OF CONSTANT, 18,0828 */ 


DECLARE HUNDREDSK (4) BYTE DATA (— 
 GAOH, G86H,0G1H,000H ); 


D DECLARATION OF ISBC941 PORT ENABLES */ 


DECLARE ENABLESFREQ. LITERALLY '@1H'; 
_ DECLARE DISABLESFREQ LITERALLY "OOH'; 


-/* DECLARATION OF ISBC 941 MEMORY LOCATION COMMANDS */ 


DECLARE WRRMS55 LITERALLY '@55H'; 
DECLARE WRRM$74 LITERALLY '074H'; 


ok DECLARATION OF VARIABLES USED IN COMPUTATI ONS */ 


DECLARE (RANGE, FREQA) BYTE; 
. DECLARE RSG ADDRESS; © 


- /* BEGIN COMPUTATION oF ‘OUTPUT FOR eid ea 48 HZ. */ 


IF FREQ > a 
THEN DO; . 


/* ENABLE FREQUENCY OUTPUT. ay 
| | DO WHILE Ccrnpur (UPTSes7A7US) AND IBF) <> 0); 


END; 
_ OUTEUT (UPT$@SCOMMAND) = SETOE; 
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DO WHILE ((INPUT(UPIS@SSTATUS) AND IBF) <> @); 
END; 


OUTPUT (UPIS@SDATA) = ENABLESFREQ; 


/* COMPUTATION OF FREQUENCY RANGE */ 
IF FREQ < 285 
THEN DO; 
IF FREQ < 226 
THEN DO; 
IF FREQ < 166 | 
THEN RANGE = 9; 
ELSE RANGE = 5; 
END; Shed 
ELSE RANGE = 3; 


END; | 
ELSE RANGE = 2; 


/* LOAD MATH ACCUMULATOR WITH 100,008 */ 
CALL MQULD4 (.IR,.HUNDREDSK); 


/* TEST FOR MOTOR SHUTDOWN */ 
IF FREQ > 1 
THEN DO; 


/* DIVIDE BY FREQUENCY */ | 
CALL MQUDV2 (.IR,.FREQ); 


/* DIVIDE BY RNAGE FACTOR */ 
CALL MQUDV1 (.IR,.RANGE); 


/* GET TWO'S COMPLEMENT FOR ISBC 941 SCALE FACTOR */ 
| CALL MQUST1 (.IR,.FREQA); 
FREQA = NOT .(FREQA + 1); 
END; , ok 


/* ADJUST FOR MOTOR STOP SIGNAL */ . 


ELSE DO; 
: FREOA = QOH; 
RANGE = @FFH; 
END; | 


/* SEND NEW SCALE FACTOR TO DEVICE */ 


DO WHILE» ( (INPUT (UPI$@$STATUS) AND IBF) <> @); 
END; | 


OUTPUT (UPIS@SCOMMAND) = WRRMS$S55; 


DO WHILE ( (INPUT (UPIS@SSTATUS ) AND IBF) <> @); 
END; a 
OUTPUT (UPIS@SDATA) = FREQA; 


/* SEND NEW PERIOD TO DEVICE */ 


DO WHILE CCENE OT (eee eesti) AND IBF) <> @); 
END; © 


OUTPUT (UPI$@SCOMMAND) = WRRMS74; 
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DO WHILE ( (INPUT (UPISO$STATUS) AND IBF) <> 0); 


END; 
OUTPUT (UPIS@SDATA) = RANGE; 


/* END OF FREQUENCY OUTPUT ee ae 
END; 


/* HANDLE ERERUENCTES < 30 HZ. */ 


ELSE DO; 


/* DISABLE FREQUENCY OUTPUT GENERATION */ 


DO WHILE ((INPUT(UPIS@SSTATUS) AND IBF) <> @); 


END; 
OUTPUT (UPISOSCOMMAND) = SETOE; 


DO WHILE ( (INPUT (UPIS@8$STATUS) AND IBF) 


END; , 
OUTPUT (UPIS@SDATA) = DISABLESFREQ; 


/* END OF ALTERNATE FREQUENCY OUTPUT */ 
END; 


/* RETURN TO CALLING PROGRAM rae 
RETURN; 


END WEIGHBELTSMOTORSDRIVE; 
SEJECT 


<> 6); 


[J RERERKEREKERE RRR EKER RRR ERE RE RRR REE EKERERERREERKEERESR 


* THIS PROGRAM GETS THE WEIGHBELT WEIGHT FROM THE 
* NUMBER 1 ISBC 941 PROCESSOR. THE WEIGHT WILL BE 
* RECEIVED AS A COUNT WHICH RANGES BETWEEN @ AND 

* 2620, Ono Nee TO A WEIGHT BETWEEN @.@ AND 
* 12.08 POUNDS. EACH COUNS RECEIVED HAS A VALUE 
k 
* 


OF @.805 POUNDS. 


USSG I IGG II IGG IO GCI ICCTA TOI EE 


WEIGHBELTSWEIGHT: PROCEDURE ADDRESS PUBLIC; 


* 
* 
* 
* 
* 
/ 


/* DECLARATIONS OF VARIABLES USED IN THE PROCEDURE */ 


DECLARE (LCOUNT,HCOUNT) BYTE; 
DECLARE WEIGHT ADDRESS ; 


ie GET INPUT COUNT LOW BYTE ay 


DO WHILE EAN POE eer no) AND IBF) <> @); 


END; 
OUTPUT (UPI$1$COMMAND) = RDFCO; 


DO WHILE ( (INPUT (UPIS1SSTATUS) AND OBF) = 
END ; 


LCOUNT = INPUT (UPI$1$DATA) ; 
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/* GET INPUT COUNT HIGH BYTE */ 
DO WHILE. -((INPUT (UPIS1SSTATUS ) AND. IBF) <> @); 
END; 
OUTPUT (UPISISCOMMAND) = RDFC1; 


DO WHILE ( (INPUT (UPI$1$STATUS) AND OBF) = @); 
END; | 
HCOUNT = INPUT (UPISI1SDATA) ; 


/* START NEXT WEIGHT SAMPLE PERIOD */ 
DO WHILE ((INPUT(UPISISSTATUS) AND IBF) <> Q@); 
END; 
OUTPUT (UPIS1SCOMMAND) = LOOP; 


/* CONVERT WEIGHT TO AN ADDRESS ‘VALUE ay 
WEIGHT = HCOUNT; 
WEIGHT = SHL(WEIGHT,8);. 
WEIGHT = WEIGHT + LCOUNT; 


/* DIVIDE BY TWO TO CONVERT TO POUNDS */ 
WEIGHT = SHR(WEIGHT,1); 


/* RETURN THE WEIGHTBELT WEIGHT oe 
' RETURN WEIGHT; 


END WEIGHBELTSWEIGHT; 

SEJECT | 

[J RRRER REIKI KEKE RR KE RERER KER ER ERE RRERREEREREREREEE 
* THIS PROCEDURE TRANFERS THE WEIGHBELT SPEED TO * 


* THE CALLING PROGRAM AND CLEARS THE COUNTER FOR #* 
* THE NEXT TEST. THE SPEED RESOLUTION PROVIDES * 
* ONLY FIVE SPEED RANGES. | - 
KKK KKK KKK KKK KEKE KKK KEKE KEKE ER REE REE RIKER ERK EREEE / 


WEIGHBELTSSPEED: PROCEDURE BYTE PUBLIC; 


/* DECLARATIONS OF VARIABLES USED BY THE PROCEDURE */ 
DECLARE SPEED BYTE; 


/* LATCH COUNTER BEFORE READING SPEED */ 
DISABLE; 


J * GET COUNTER VALUE FROM COUNTER a4 
Speee = BRET SCOUNE: 


f* CLEAR COUNTER FOR NEXT OPERATION */ 
BELTSCOUNT = @; © 
ENABLE; 


/* RETURN DATA: TO:CALLING ROUTINE */ |. 
RETURN SPEED; fo ie 


END WEIGHBELTSS PEED; 
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SEJECT 
OCC CIGGIGIGIOIIOIGIGIGOIIO ITO A CT CCCICICICICI ICICI TOR ICICI OCC 


* THIS PROCEDURE PROVIDES COMMANDS TO THE STEPPER * 


* MOTOR TO OPERATE THE CONTROL VALVE. IT WILL COM-* 
* PUTE THE SIGNED MAGNITUDE REPRESENTATION FROM * 
* THE TWO'S COMPLIMENT INPUT AND WILL ISSUE THE sd 
* APPROPRIATE STEP INCREMENT AND DIRECTION. A il 
* FIXED STEP RATE OF 18@ STEPS PER SECOND WILL BE * 
* USED BY THE CONTROL DEVICE. * 
* 


KREKKKEEKEKE EERE KEKE EKER EERE KERR EER EERE EERE KEEKE / 


~LIQUIDSVALVESPOSITION: PROCEDURE (POSITION) PUBLIC; 


/* DECLARATIONS OF VARIABLES USED BY THE PROCEDURE */ 
DECLARE POSITION BYTE; 


/* DEFINITIONS OF TERMS USED IN COMPUTATIONS */ 
DECLARE STEPSRATE LITERALLY '@@5H'; 
DECLARE REVERSE #£LITERALLY 'O8GH'; 


/* IF NO MOVEMENT, SKIP OPERATIONS */ 
IF POSITION <> @ © 
THEN DO; 


/* SUPPORT CONVERSION TO SIGNED MAGNITUDE NUMBER */ 
IF POSITION > 127 
THEN DO; 


f* GET MAGNITUDE OF MOVEMENT */ 


POSITION = 256 ~— POSITION; 


i> SET SIGN FOR CCW ROTATION */ 
POSITION = POSITION. OR REVERSE; 
END; | | 


/* VERIFY THAT QUEUE SPACE IS AVAILABLE */ 


DO WHILE ei a lca, AND QF) <> @); 
END; 


/* REQUEST DESIRED Sip RATE +/ 
“DO WHILE ( (INPUT (UPI$2$STATUS) AND IBF) <> B); 
END; | 


OUTPUT (UPIS2SDATA) = STEPSRATE; 


/* REQUEST STEPPER MOVEMENT */ a 
DO WHILE ((INPUT(UPI$2$STATUS) AND IBF) <> 9); 
END; 
OUTPUT (UPIS2SDATA) = POSITION; 
END; a8 


/* RETURN TO CALLING ‘PROGRAM fe 
| RETURN; 


END LIQUIDSVALVESPOSITION; 
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SEJECT 
J BRREKRERRERER ERE ER ER KER KK ERE RRR EKE ERK REKEKRERKEKREREKRKEEKKKE 


* 


* 
* 
* 
* 
* 
* 
* 
* 


KKEKKEKKEKEK KEKE EKER KEKE EKER KRKKKKKKKKKKSE 


THIS PROCEDURE TRANSFERS THE LIQUID FLOW RATE FROM * 
THE FLOW COUNTER TO THE CALLING PROGRAM. AFTER 
READING, THE FLOW COUNTER WILL BE RESET TO FACILI- 
TATE THE NEXT READING. THE LIQUID FLOW COUNT WILL 
VARY BETWEEN 29 AND 24@ PULSES IN EACH 20@@ MILLI- 
SECOND SAMPLE INTERVAL. THIS WILL CORRESPOND TO 
THE ACTUAL LIQUID FLOW RATE OF 19 TO 12@ POUNDS 
PER MINUTE. 


N+ HOF OF OF 


LIQUIDSFLOWSRATE: PROCEDURE ADDRESS PUBLIC; 


/* DECLARATION OF VARIABLES USED BY THE PROGRAM */ 


DECLARE TEMP BYTE; 
DECLARE (FLOW, TSTWO,TSSXTN, TSTHRTWO) ADDRESS; 


/* LATCH COUNTER BEFORE READING FLOW */ 


DISABLE; 


/* GET FLOW RATE VALUE FROM COUNTER */ 


TEMP = LIQSCOUNT; 


/* CLEAR COUNTER FOR NEXT OPERATION */ 


LIQSCOUNT = @; 
ENABLE; 


/* CONVERT TO POUNDS PER MINUTE */ 


FLOW = TEMP; 

TSTWO = SHL(FLOW,1); 

TSSXTN = SHL(TSTWO,3); 

TSTHRTWO = SHL(TSSXTN,1); 

FLOW = TSTWO + TSSXTN + TSTHRTWO; 


/* RETURN FLOW RATE TO CALLING PROGRAM */ 


RETURN FLOW; 


END LIQUIDSFLOWSRATE; 


SEJECT 
[J RREREKRKRK KEKE EKER KEKE RR KEE ERR ERE RE RREKKERKKKES 


* 


COUNTER FOR LIQUID FLOW RATE FROM LIQUID * 


* FLOW METER. COUNT PULSE WILL GENERATE AN * 
* 


* INTERRUPT AT LEVEL l. 
KAR KEK KKK KEKE KK ERR KKK KHER KK ARE RRR KER ERER ERK / 


LIQSCNT: PROCEDURE INTERRUPT 1 PUBLIC; 


/* INCREMENT FLOW COUNT */ 


LIQSCOUNT = LIQSCOUNT + 1; 


/* SEND END OF INTERRUPT */ 


OUTPUT (@ECH) = @2@H; 
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) 


RETURN -*/ 
174,.:.2.: - ..... RETURN; . 


175-20" END LIOSCNT; 
—  SEJECT 


ieee ELLE LLLLLLLLLLLLLLLLELL LLL 
_* THIS PROCEDURE WILL PROVIDE AN EVENT COUN-* 

* TER TO HANDLE THE BELT MOTION DETECTOR. . * 

* IT WILL OPERATE. BY DIRECTING THE MOTION * 


-* PULSE TO INTERRUPT 2. * 
KEKEKKKEKKKEKEKKEEKRERE EKER ERE RE EKREKRKEREREREKREE / 


176 1 BELTSCNT: PROCEDURE egos ae ee ees 


. _ /* INCREMENT BELT MOVEMENT a 
177 2 BELTSCOUNT = BELTSCOUNT + 1; 
/* SEND END OF INTERRUPT */ _ 
178 2 OUTPUT (GECH) = @28H; 
/* RETURN */ 
179 2 RETURN; 
180 2 “END BELTSCNT; 
181 1 END PROCESSOR $INTERFACE$MODULE ; 


MODULE INFORMATION: 


CODE AREA SIZE = @251H  . 593D 
VARIABLE AREA SIZE = @013H 19D 
MAXIMUM STACK SIZE = 


OGO8H 8D 
46@ LINES READ — ; 
@ PROGRAM ERROR (S) 


END OF PL/M-8@ COMPILATION 


3-122 AFN-01931A 


intel ARTICLE  AR-91 
REPRINT 


3-123 AFN-01931A 


“de Syetenns ¢ Grows Easier 


Although a single data bus standard yet eludes the microcomputer industry, numer- 
ous manufacturers of single-board computer and supplementary boards have cast a 
hardware vote for the Multibus, Intel’s microcomputer backplane which they origina- 
ted in 1976. With a steady eye on the control industry market, Intel has designed a 
home to accommodate Multibus compatible equipment, the iCS-80 industrial chas- 
sis. It promises to significantly reduce the time and cost of assembling the housing 
and interface parts of amicrocomputer-based control system. Inthis article, besides 
taking the first look at Intel’s new chassis and signal conditioning panels, we've put 


together a comprehensive list of Multibus compatible equipment. 


MICHAEL J. MCGOWAN, Control Engineering 


After the development of single-board 
computers nearly three years ago, ven- 
dors moved quickly to seize a fraction of 
the market. It seemed at first that every- 
thing from memories to analog 1/O 
boards had become available. With an 
astonishing suddenness, companies 
sprang up in Silicon Valley, Texas, New 
Jersey, and along the forested roadside 
of Rt. 128 outside of Boston. Late that 
year, we counted well over a hundred 
companies anxious to make their for- 
tune selling the control engineer every- 
thing from one or two interface boards 
to complete microprocessor systems. 
Then the pleasant dream became a 
nightmare. From power supply require- 
ments to backplane pinouts, little was 


compatible. Even such an obvious thing | 


as board size differed from vendor .to 


vendor and many a hope for an ideal. 


system was crushed in a pragmatic 
search for whatever would fit together. 

seven months ago in our June 1978 
issue we noted that the number of mi- 


crocomputer system manufacturers . 
had dwindled to about 60 and since 


then, we find still fewer. Some, no doubt, 
were forced out for lack of reliability, 
though most, despite remarkably ta- 
lented engineering, starved as the mar- 
ket saturated. 

Large scale integration of microcom- 
puter components has more than 
doubled the memory size of single- 
board computers. Sixteen bit word 
lengths will become commonplace in 
the next year as microcomputer perfor- 
mance begins to rival the mini- 
computer's and the lines: of distinc- 
tion between micros and minis fades. 

The fight for a standard data bus 
drags on with leaders in the struggle. but 


no winner. On the offensive, Pro-Log. 
and Mostek jointly introduced the STD | 


bus last autumn in an attempt to gaina 
greater market share by espousing de- 
centralized system architectures. Their 
philosophy argues economics: the user 
should pay only for essential functions 
by selecting small, specialized boards 


and not squander funds on a general 
purpose board with extra features. 

Still, Intel, favoring more densely 
packed and versatile boards, continues 
to dominate the market while the Multi- 
bus retains its popularity. Today more 
30 manufacturers produce over one 
hundred different boards based on that 
bus structure alone. Not that Intel enjoys 
the strict fidelity of its outside vendors; 
Digital Equipment Corporation, for in- 
stance, boasts some 17 companies 
providing boards to mate with the 
LSI-11 and LSI-112. 
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But perhaps alone among its compet- 
itors, Intel has recognized that the ma-. 
jority of its boards are being used in 
industrial applications and that the con- 
trol system designer needs more than 
components. 


An industrial chassis 

A microcomputer system designer must 
choose components that are electro- 
mechanically compatible. To that end, 
Intel is introducing the iCS-80 industrial 
chassis and termination panels. It 
makes all Multibus-compatible CPU 
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and peripheral boards readily usable. 

The advantage of the ICS-80 is that 
most of the interconnection and me- 
chanical details for assembling a 
microcomputer-based control system 
have already been worked out. . 

The iCS-80 stands 15.75 inches high 
and can be mounted in a stardard 
RETMA 19 inch rack, or ina NEMA cabi- 
net secure from the industrial environ- 
ment. The minimum layout consists of a 
four-slot Multibus card cage with provi- 
sions for adding two more cages to a 
maximum of twelve cards. The cages fit 
vertically, like records in a rack, to aid 
convection cooling and permit front ac- 
cess for insertion and maintenance. _ 

On the right. side of the chassis is 
room for either a 14 or 30 ampere power 
supply, the choice dictated by the ap- 
plication. The system will operate on 
either 115 or 230 volts with a range of 47 
to 63 Hertz. specified in anticipation of 
international service. 

Cooling is assisted by four fans— 
three for the card cages and one for the 
power supply section. The intention 
here is to make the installation of addi- 
tional fans unnecessary even after the 
system has expanded. The fans are ex- 
pected to provide adequate cooling for 
most applications so supplementary air 
conditioning can be eliminated or at 
least minimized. 


Signal conditioning 

Three signal conditioning sance have 
been developed by Intel to simplify con- 
nections between the processing cards 
and the outside world. The principle is 
neatness, and with that follows reliabil- 
ity. Flat ribbon cables connectthe sig- 
nal conditioners to the processor cards, 
a safeguard from ‘which wire is which” 
and screwdriver slips in the vicinity of 
expensive boards. Field connections to 
the external inputs and outputs are 
made (presumably by electricians with 
big hands and reputations for being 
less than delicate) through rugged, 
screw-type barrier strips that accept 
wire as heavy as 14 AWG. The panels 
can mount either on RETMA cabinet 
brackets, NEMA wall spacers, or on the 
iCS-80 chassis itself. 

Each signal conditioning card gives 
the user a variety of options. The iCS-910 
analog signal conditioning/termination 
panel accepts up to 16 differential or 32 
single ended input channels. The four 
2-wire analog output channels might be 
connected to 4 to 20 mA current loops. 

The digital signal conditioning termi- 
nation panel, iCS-920, handles 24 two- 
wire input or output channels with sig- 
nals up to 55 V, 300 mA. Inputs can be 
diode protected, and pads are pro- 
vided for current limiters or voltage di- 
viders. Optoisolators may be inserted in 


Vendors of Multicompatible Boards 


ADAC Corp. 
Woburn, MA 
617/935-6668 

- Advanced Micro Computers 
Santa Clara, CA 
~ 408/732-2400 — 

~ Ampex 
El Segundo, CA 
714/973-2970 

Analog Devices 
Norwood, MA 
617/329-4700 — 

Augat . 
Attleboro, MA 
617/222-2202 

Burr-Brown 
Tucson, AZ 
602/655-8000 

Computer Marketing 
Waltham, MA 
617/894-7000 

Data Translation 
Natick, MA 
617/655-5300 

Datacube 
Reading, MA 
617/944-4600 

Datel Systems 

Canton, MA 
617/828-8000 

Electronic Solutions 
San Diego, CA 
714/292-0242 

Garry Manufacturing 

~ New Brunswick, NJ 
212/267-6844 

HT Instruments 
Marina Del Rey, CA 
312/822-4296 

Hal Communications 
Urbana, IL 
217/367-7373 

Heurikon 
Madison, WI 
608/255-9075 

IDEAS 
Beltsville, MD 
301/937-3600 

~ Intel 
Aloha, OR 
503/642-2563 

Interphase 
Dallas, TX 
214/238-0971 


the DIP sockets for high voltage isola- : 
tion or jumpers may be used instead 


when the input is TTL. Similarly, output - 


sockets accept jumpers for direct TTL 
output, DIP optoisolators for transient 
suppression, or integrated circuit (open 
collector) drivers for high voltage’ to 
high current outputs. Activity on each 
Channel is indicated by LEDs. 

The ac signal conditioning/(solidas) 


_termination panel, iCS-930, will actually 


work with ac or dc on its 16 channels. 
The user supplies optoisolators for input 
isolation and optically-isolated solid 
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Matrox Electronic Systems 
Montreal, Quebec 
514/735-1182 

Megalogic 
Brookville, OH 
513/833-5222 


- Micro Memories 


Chatsworth, CA 
213/998-0070 
“Micro Networks 
Worcester, MA 
617/852-5400 
_ MicroTec 
Sunnyvale, CA 
408/733-2919. 
Micro/Tel 
St. Louis, MO 
314/569-3450 
Monolithic Systems 
Englewood, CO 
303/770-7400 
Motorola 
Austin, TX 
512/928-6572 
MUPRO 
Sunnyvale, CA 
408/737-0500 
National Semiconductor 
Santa Clara, CA 
408/737-5262 
North Star Computers 
Berkeley, CA 
415/549-0858 
Pertec (ICOM) 
Chatsworth, CA 
213/998-1800 - 
Relational Memory Systems 
San Jose, CA 
408/248-6356 
Systems; Computers and Interfaces 
Waltham, MA 
617/899-2359 
Thomas Engineering Co. 
Concord, CA 
415/686-3041 
Vector Electronic 
Sylmar, CA 
213/365-9661 
XEDAX 
Alameda, CA | 
415/521-6600 
ZIA Tech . 
Cupertino, CA 
408/996-7082 


state relays for output isolation. Mount- 
ing pads for customer-supplied MOVs 
or snubber networks are included. As 
before, a fuse gives overload protection 
and LEDs indicate channel activity. 
The advantage of all this is that by 
plugging in some components and per- 
haps inserting a few resistors and capa- 
citors, the interface units canbe tailored 
to a particular application. Since many 
mechanical and electrical connection 
problems have already been solved, a : 
customized unit can be built with mini- 
mum effort. 3 a el 
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iSBC 534 Four Channel Communications Expansion Board Hardware Reference Manual, 9800450 

RMX/80 Interactive Configuration Utility User’s Guide, 142603 —— 
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iSBC 88/40 Hardware Reference Manual 
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Bubble Memory Design Handbook 
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MCS 48 Reference Card (98-412) 
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AR 63 — Microcomputer’s On-Chip Functions — 8022 (98-780) 
AR 102 — Designing Reliable Software for Auto Applications 
AR 107 — Use EPROM 1-Chip »Cs as Effective 1-Shot Lab Aids 
UPI-41 User’s Manual 
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4-6 


Part No. 


011100 
010100 
001710 
006540 
006560 
006700 
006720 
006740 
006750 
006760 
006771 
006775 
006780 
006900 
007300 
007320 
007330 
007370 
008300 
008500 
008550 
008560 


007375 
007380 
007385 
007400 


900020 
900500 
900515 
900520 


98-270 
201710 
121511 
202300 
203800 
203805 
203810 
203815 
203820 
203605 
203610 
207350 
207355 

98-504 
203100 

98-255 

98-153 
207100 

98-366 
205770 
205785 
207715 

98-940 

98-452 


AFN-01931A 


Title Part No. 
MCS-86 User’s Manual 98-722 
MCS-86 Product Description (98-723) 205880 
AR 74.— Get Minicomputer Features at 10 x Speed with 8086 (98-921) 207310 
AR 82 — CPU Brings 6-Bit Performance (98-957) 207320 
AP: 50 — Debug Strategies for 8089 207755 
AP 51 — Design 8086/8088/8089 with 8289 207760 
MCS-86 Assembly Macro Language Reference Manual 98-640 
MCS-86 Assembly Language Reference Guide (98-749) 205900 
Peripheral Design Handbook 98-676 
Peripherals Product Description 205600 
Microcomputers and Peripherals Pocket Guide (98-843) 205615 
AR 53 — Micro Interfacing Characteristics (8253) — (98-647) 207305 
AR 89 — Powerful I/O Processor Unloads CPU (8089) 207330 
AP 15 — 8255 Programmable Peripheral Interface (98-333) 207700 
AP 16 — Using the 8251 (98-334) 207705 
AP 31 — Using the 8259 (98-658) 207720 
AP 32 — 8275 and 8279 (98-576) 207725 
AP 35 — Crystals Specifications (98-652) 207730 
AP 45 — Using the 8202 Dynamic RAM Controller (98-809) 207745 
AP 48. — Direct Memory Access w/8257 DMA Controller 207750 
AP 54 — Dot Matrix Printer Controller Using the 8295 (98-816) 207765 
AP 59 — Using 8259A Programmable Interrupt Controller 207770 
INDUSTRIAL GRADE PRODUCTS 
Industrial Environment Brochure 206000 
Industrial Grade Product Book 206005 » 
MILITARY COMPONENTS | 
Military Products Data Catalog 004150 
GENERAL DATA CATALOGS - . 
1979 Components Data Catalog 010200 
1979 Systems Data Catalog 506000 
PROTOTYPE MICROCOMPUTER KITS | 
SDK-85 User’s Manual 98-451 
SDK-86 Assembly Manual 98-697 
SDK-86 User’s Guide 98-698 
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Tel: (404) 449-0541 


ILLINOIS 


Intel Corp. °* 
2560 Golf Road, Suite 815 
Rolling Meadows 60008 
Tel: (312) 981-7200 

TWX: 910-65 1-588 1 


INDIANA 


Intel Corp. 

9101 Wesleyan Road 
Suite 204 
Indianapolis 46268 
Tel: (317) 875-0623 


1OWA 


Intel Corp. 

St. Andrews Building 

1930 St. Andrews Drive N.E. 
Cedar Rapids 52402 

Tel: (319) 393-5510 


KANSAS 


Intel Corp. 

9393 W. 110th St., Ste. 265 
Overland Park 66210 

Tel: (913) 642-8080 


MARYLAND 


Intel Corp. * 

7257 Parkway Drive 
Hanover 21076 

Tel: (301) 796-7500 


TWX: 710-862-1944 


MASSACHUSETTS 


Intel Corp. ° 

27 Industrial Ave. 
Chelmsford 01824 
Tel: (617) 256-1800 
TWX: 710-343-6333 


EMC Corp. 

381 Elliot Street 
Newton 02164 

Tel: (617) 244-4740 
TWX: 922531 


MICHIGAN 


Intel Corp. ° 

26500 Northwestern Hwy. 
Suite 401 

Southfield 48075 

Tel: (313) 353-0920 
TWX: 810-244-4915 


MINNESOTA 


_Intel Corp. 


7401 Metro Bivd. 
Suite 355 

Edina 55435 

Tel: (612).835-6722 
TWX: 910-576-2867 


MISSOURI 


intel Corp. 

502 Earth City Plaza 
Suite 121 

Earth City 63045 
Tel: (314) 291-1990 


NEW JERSEY 


Intel Corp. * 

Raritan Plaza 

2nd Floor 

Raritan Center 
Edison 08837 

Tel: (201) 225-3000 
TWX: 710-480-6238 


M. T. |. 


383 Route 46 West 
Fairfield, NJ 07006 


NEW MEXICO 


BFA Corporation 
P.O. Box 1237 

Las Cruces 88001 
Tel: (505) 523-0601 
TWX: 910-983-0543 


BFA Corporation 

3705 Westerfield, N.E. 
Albuquerque 87111 
Tel: (505) 292-1212 
TWX: 910-989-1157 


NEW YORK 


intel Corp. °* 

300 Motor Pkwy. 
Hauppauge 11787 
Tel: (516) 231-3300 
TWX: 510-227-6236 


Intel Corp. 

80 Washington St. 
Poughkeepsie 12601 
Tel: (914) 473-2303 
TWX: 510-248-0060 


Intel Corp. * 

2255 Lyell Avenue 
Lower Floor East Suite 
Rochester 14606 

Tel: (716) 254-6120 
TWX: 510-253-7391 


T-Squared 

4054 Newcourt Avenue 
Syracuse 13206 

Tel: (315) 463-8592 
TWX: 710-541-0554 


T-Squared 

7353 Pittsburgh 
Victor Road 

Victor 14564 

Tel: (716) 924-9101 
TWX: 510-254-8542 


NORTH CAROLINA 


‘Intel Corp. 
2306 W. Meadowview Rd. 
Suite 206 
Greensboro 27407 
Tel: (919) 294-1541 


OHIO 


Intel Corp.* 

6500 Poe Avenue 
Dayton 45414 

Tel: (513) 890-5350 
TWX: 810-450-2528 


Intel Corp. ° ; 
Chagrin-Brainard Bidg.,.No. 300 
28001 Chagrin Blvd. 

Cleveland 44122 

Tel: (216) 464-2736 

TWX: 810-427-9298 


OREGON 


Intel Corp. 

10700 S.W. Beaverton 
Hillsdale Highway 
Suite 324 

Beaverton 97005 

Tel: (503) 641-8086 
TWX: 910-467-8741 


PENNSYLVANIA 


Intel Corp. * 

510 Pennsylvania Avenue 
Fort Washington 19034 
Tel: (215) 641-1000 
TWX: 510-661-2077 


Intel Corp. * 

201 Penn Center Boulevard 
Suite 301W 

Pittsburgh 15235 

Tel: (412) 823-4970 


. Q.E.D. Electronics 
300 N. York Road 
Hatboro 19040 
Tel: (215) 674-9600 
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TEXAS 


Intel Corp. ° 

2925 L.B.J. Freeway 
Suite 175 

Dallas 75234 

Tel: (214) 241-9521 

TWX: 910-860-5617 


Intel Corp. ° 


‘6420 Richmond Ave. 


Suite 280 

Houston 77057 

Tel: (713) 784-3400 
TWX: 910-881-2490 


Industrial Digital Systems Corp. 
5925 Sovereign 

Suite 101 

Houston 77036 

Tel: (713) 988-9421 


Intel Corp. 

313 E. Anderson Lane 
Suite 314 

Austin 78752 

Tel: (512) 454-3628 


UTAH 


Intel Corp. (temporary) 
3519 Lexington Dr. 
Bountiful, UT 84010 
Tel: (801) 292-2164 


VIRGINIA 


Intel Corp. 

1501 Santa Rosa Road 
Suite C-7 

Richmond, VA 23288 
Tel: (804) 282-5668 


WASHINGTON 


Intel Corp. 
Suite 114, Bidg. 3 
1603 116th Ave. N.E. 


. Bellevue 98005 


Tel: (206) 453-8086 
TWX: 910-443-3002 


' WISCONSIN 


Intel Corp. 

150 S. Sunnysiope Rd. 
Brookfield 53005 

Tel: (414) 784-9060 


“CANADA 


intel Semiconductor Corp.° 
Suite 233, Bell Mews 

39 Highway 7, Bells Corners 
Ottawa, Ontario K2H 8R2 
Tel: (613) 829-9714 

TELEX: 053-4115 


Intel Semiconductor Corp. © 
50 Galaxy Blvd. 

Unit 12 

Rexdale, Ontario 

M9OW 4Y5 

Tel: (416) 675-2105 
TELEX: 06983574 


Multilek, Inc. ° 

15 Grenfell Crescent 
Ottawa, Ontario K2G 0G3 
Tel: (613) 226-2365 
TELEX: 053-4585 
Multilek, Inc. * 
Toronto 

Tel: 1-800-267-1070 
Multilek, inc. 
Montreal 

Tel: 1-800-267-1070 


*Field Application Location 


3065 Bowers Avenue , 
Santa Clara, California 95051 
Tel: (408) 987-8080. 
TWX: 910-338-0026 

TELEX: 34-6372 


ALABAMA 


Arrow Electronics 
4717 University Dr. 
Suite 102 1/2 D. 
Huntsville 35405 
Tel: (205) 830-1103 


tHamilton/ Avnet Electronics 


4812 Commercial Drive N.W. 


Huntsville 35805 
Tel: (205) 837-7210 
TWX: 810-726-2162 


t Pioneer /Huntsville 

1207 Putnam Drive N.W. 
Huntsville 35805 - 
Tel: (205) 837-9300 
TWX: 810-726-2197 


ARIZONA 


tHamilton/ Avnet Electronics 
505 S. Madison Drive 
Tempe, AZ 85281 

Tel: (602) 231-5140 

TWX: 910-950-0077 


tWyle Distribution Group 
8155 N. 24th Street 
Phoenix 85021 

Tel: (602) 995-9185 
TWX: 910-951-4282 


CALIFORNIA 


Arrow Electronics, Inc. 
521 Weddell Dr. 
Sunnyvale 94086 

Tel: (408) 745-6600 
TWX: 910-339-937 1 


tAvnet Electronics 

350 McCormick Avenue 
Costa Mesa 92626 
Tel: (714) 754-6051 
TWX: 910-595-1928 


Hamilton/Avnet Electronics 
1175 Bordeaux Dr. 
Sunnyvale 94086 

Tel: (408) 743-3300 

TWX: 910-339-9332 


tHamiiton/ Avnet Electronics 
4545 Viewridge Ave 

San Diego 92123 

Tel: (714) 563-1969 

TWX: 910-335-1216 


tHamiiton/ Avnet Electronics 
10912 W. Washington Bivd. 
Culver City 90230 
Tel: (213) 558-2193 

TWX: 910-340-6364 or 7073 


tHamiiton Electro Sales 
3170 Pullman Street 
Costa Mesa 92626 

Tel: (714) 641-4109 
TWX: 910-595-2638 


tWyle Distribution Group 
124 Maryland Street 

El. Segundo 90245 

Tel: (213) 322-8100 

TWX: 910-348-7140 of 7111 


tWyle Distribution Group 
9525 Chesapeake Dr. 
San Diego 92123 

Tei: (714) 565-9171 
TWX: 910-335-1590 


tWyle Distribution Group 
3000 Bowers Avenue 

Santa Clara 95052 

Tel: (408) 727-2500 
TWX: 910-338-0451 or 0296 


Wyle Distribution Group 
17872 Cowan Avenue 
irvine 92713 

Tel: (714) 641-1600 
TWX: 910-595-1572 


COLORADO 


tWyle Distribution Group 
451E 124th Avenue 
Thornton, CO 80241 
Tel: (303) 457-9953 
TWX: 910-936-0770 


tHamilton/ Avnet Electronics 
8765 E. Orchard Road 

Suite 708 

Englewood 80111 

Tel: (303) 740-1017 

TWX: 910-935-0787 


CONNECTICUT 


tArrow Electonics 
12 Beaumont Road 
Wallingford 06512 
Tel: (203) 265-7741 
TWX: 710-476-0162 


tHamilton/ Avnet Electronics 
Commerce Industrial Park 
Commerce Drive 


‘Danbury 06810 


Tel: (203) 797-2800 
TWX: 710-456-9974 


tHarvey Electronics 
112 Main Street 
Norwalk 06851 

Tel: (203) 853-1515 
TWX: 710-468-3373 


FLORIDA 


tArrow Electronics 
1001 N.W. 62nd Street 
Suite 108 

Ft. Lauderdale 33309 
Tel: (305) 776-7790 
TWX: 510-955-9456 


tArrow Electronics 

115 Palm Bay Road, N.W. 
Suite 10, Bldg. 200 

Palm Bay 32905 

Tel: (305) 725-1480 
TWX: 510-959-6337 


tHamilton/ Avnet Electronics 
6800 Northwest 20th Ave. 
Ft. Lauderdale 33309 

Tel: (305) 971-2900 

TWX: 510-956-3097 


Hamilton / Avnet Electronics 
3197 Tech. Drive North 

St. Petersburg 33702 

Tel: (813) 576-3930 

TWX: 810-863-0374 


tPioneer/ Orlando 

6220 S. Orange Biossom Trail 
Suite 412 

Orlando 32809 

Tel: (305) 859-3600 


TWX: 810-850-0177 
GEORGIA 


Arrow Electronics 
2979 Pacific Drive 
Norcross 30071 
Tel: (404) 449-8252 
TWX: 810-766-0439 


. tHamilton/ Avnet Electronics 


5825 D. Peachtree Corners 


Norcross 30092 


Tel: (404) 447-7500 
TWX: 810-766-0432 


Pioneer/ Georgia 

5835 B Peachtree Corners E 
Norcross 30092 

Tel: (404) 448-1711 


_ TWX: 810-766-4515 
* ILLINOIS 


Arrow Electronics 


‘492 Lunt Avenue 


P.O. Box 94248 

Schaumburg 60172 
Tel: (312) 893-9420 
TWX: 910-291-3544 


tHamilton/ Avnet Electronics 


- 3901 No. 25th Avenue 


Schiller Park 60176 
Tel: (312) 678-6310 
TWX: 910-227-0060 


Pioneer/ Chicago 
1551 Carmen Drive 


Elk Grove 60007 - 


Tel: (312) 437-9680 
TWX: 910-222-1834 


INDIANA 


Arrow Electronics 
2718 Rand Road 
indianapolis 46241 
(317) 243-9353 
TWX: 810-341-3119 


tHamilton/ Avnet Electronics 
485 Gradle Drive 

Carmel 46032 

Tel: (317) 844-9333 

TWX: 810-260-3966 


INDIANA (Cont.) 


Pioneer /indiana 

6408 Castlepiace Drive 
Indianapolis 46250 

Tel: (317) 849-7300 
TWX: 810-260-1794 


’ KANSAS 


tHamilton/ Avnet Electronics 
9219 Quivera Road 
Overland Park 66215 

Tel: (913) 888-8900 

TWX: 910-743-0005 


tComponent Specialties, inc. 


8369 Nieman Road 
Lenexa 66214 
Tel: (913) 492-3555 


MARYLAND 


tHamilton/ Avnet Electronics 
6822 Oak Hall Lane 
Columbia, MD 21045 

Tel: (301) 995-3500 

TWX: 710-862-1861 


Mesa 

16021 Industrial Dr. 
Gaithersburg 20760 
Tel: (301) 948-4350 


+Pioneer/ Washington 
9100 Gaither Road 
Gaithersburg 20760 
Tel: (301) 948-0710 
TWX: 710-828-0545 


MASSACHUSETTS 


tHamilton/ Avnet Electronics 
50 Tower Office Park 
Woburn 01801 : 

Tel: (617) 935-9700 

TWX: 710-393-0382 


+Arrow Electronics 
Arrow Dr. 


- Woburn 01801 


Tel: (617) 933-8130 
TWX: 710-393-6770 


Harvey /Boston 

44 Hartwell Ave. 
Lexington 02173 
Tel: (617) 863-1200 
TWX: 710-326-6617 


MICHIGAN 


' tArrow Electronics 


3810 Varsity Drive 
Ann Arbor 48104 
Tel: (313) 971-8220 
TWX: 810-223-6020 


- tPioneer/Michigan 


13485 Stamford 
Livonia 48150 

Tel: (313) 525-1800 
TWX: 810-242-3271 


tHamilton/Avnet Electronics 
32487 Schoolcraft Road 
Livonia 48150 

Tel: (313) 522-4700 

TWX: 810-242-8775 


MINNESOTA 


- tArrow Electronics 


5230 W. 73rd Street 
Edina 55435 

Tel: (612) 830-1800 
TWX: 910-576-3125 


- tindustrial Components 


5229 Edina Industrial Blvd. 
Minneapolis 55435 

Tel: (612) 831-2666 
TWX: 910-576-3153 


Hamilton / Avnet Electronics 
10300 Bren Rd. East 
Minnetonka 55343 

Tel: (612) 932-0666 


. TWX: (910) 576-2720 


tHamiiton/ Avnet Electronics 
7449 Cahill Road 

Edina 55435 

Tel: (612) 941-3801 

TWX: 910-576-2720 


MISSOURI 


tArrow Electronics 
2380 Schuetz 

St. Louis, MO 63141 
Tel: (314) 567-6888 


tHamilton/ Avnet Electronics 
13743 Shorline Ct. 

Earth City 63045 

Tel: (314) 344-1200 

TWX: 910-762-0684 
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NEW HAMPSHIRE 


tArrow Electronics 
1 Perimeter Drive 
Manchester 03103 
Tel: (603) 668-6968 
TWX: 710-220-1684 


' NEW JERSEY 
. tArrow Electronics 


Pleasant Valley Avenue 
Moorestown 08057 

Tel: (215) 928-1800 
TWX: 710-897-0829 


tArrow Electronics 

285 Midiand Avenue 
Saddle Brook 07662 
Tel: (201) 797-5800 


TWX: 710-998-2206 


tHamilton/ Avnet Electronics 
1 Keystone Ave. 
Bidg. 36 

Cherry Hill 08003 

Tel: (609) 424-0100 

TWX: 710-940-0262 


Hamilton/Avnet Electronics 
10 Industrial Road 

Fairfield 07006 

Tel: (201) 575-3390 

TWX: 710-734-4388 


tHarvey Electronics 
45 Route 46 
Pinebrook 07058 
Tel: (201) 227-1262 
TWX: 710-734-4382 


Measurement Technology Sales Corp. 
383 Route 46 W 

Fairfield, NJ 07006 

Tel: (201) 227-5552 


NEW MEXICO 


’ ¢Alliance Electronics Inc. 


11030 Cochiti S.E. 

Albuquerque 87 123 
Tel: (505) 292-3360 
TWX: 910-989-1151 


tHamilton/ Avnet Electronics 
2524 Baylor Drive S.E. 
Albuquerque 87119 

Tel: (505) 765-1500 

TWX: 910-989-0614 


NEW YORK 


tArrow Electronics 

900 Broad Hollow Rd. 
Farmingdale, NY 11735 
Tel: (516) 694-6800 
TWX: 510-224-6494 


tArrow Electronics 

3000 South Winton Road 
Rochester 14623 

Tel: (716) 275-0300 
TWX: 510-253-4766 


tArrow Electronics 
7705 Maltage Drive 
Liverpool 13088 
Tel: (315) 652-1000 
TWX: 710-545-0230 


Arrow Electronics 
20 Oser Avenue 
Hauppauge 11787 
Tel: (516) 231-1000 
TWX: 510-227-6623 


tHamilton/ Avnet Electronics 
333 Metro Park 

Rochester 14623 

Tel: (716) 475-9130 

TWX: 510-253-5470 


tHamilton/ Avnet Electronics 
16 Corporate Circle 


POE, Syracuse 13057 


Tel: (315) 437-2641 
TWX: 710-541-1560 


tHamilton/ Avnet Electronics 


’ § Hub Drive 


Melville, Long Island 11746 
Tet: (516) 454-6000 


' TWX: 510-224-6166 


Harvey Electronics 
P.O. Box 1208 
Binghampton 13902 


‘Tel: (607) 748-8211 


TWX: 510-252-0893 


tMicrocomputer System Technical Demonstrator Centers 


‘4 
a 
if 
& 


3065 Bowers Avenue 

Santa Clara, California 95061 
Tel: (408) 987-8080 - 

TWX: 910-338-0026 

TELEX: 34-6372 


NEW YORK (Cont.) 


tHarvey Electronics 

60 Crossways Park West 
Woodbury, Long Isiand 11797 
Tel: (516) 921-8920 

TWX: 510-221-2184 


Harvey / Rochester 
840 Fairport Park 
Fairport 14450 

Tel: (716) 381-7070 
TWX: 510-253-7001 


Measurement Technology Sales Corp. 


169 Northern Bivd. 
Greatneck 11021 
Tel: (516) 482-3500 
TWX: 510-223-0846 


NORTH CAROLINA 


Arrow Electronics 
938 Burke Street 
Winston-Salem 27 102 
Tel: (919) 725-8711 
TWX: 510-931-3169 


tHamilton/Avnet Electronics 
2803 Industrial Drive 
Raleigh 27609 

Tel: (919) 829-8030 

TWX: 510-928-1836 


Pioneer / Carolina 
106 Industrial Ave. 
Greensboro 27406 
Tel: (919) 273-4441 
TWX: 510-925-1114 


OHIO 

Arrow Electronics 
10 Knolkrest Dr. 
Reading, OH 45237 


. Tel: (613) 761-5432 


TWX: 810-46 1-2670 


Arrow Electronics 
7620 McEwen Road 
Centerville 45459 
Tel: (513) 435-5563 
TWX: 810-459-1611 


Arrow Electronics 
6238 Cochran Rd. 
Solon 44139 

Tel: (216) 248-3990 
TWX: 810-427-9409 


tHamilton/ Avnet Electronics 
954 Senate Drive 

Dayton 45459 

Tel: (513) 433-0610 

TWX: 910-450-2531 


tHamilton/ Avnet Electronics 
4588 Emery !ndustrial Parkway 
Warrensville Heights 44128 
Tel: (216) 831-3500 

TWX: 810-427-9452 


tPioneer/Dayton 
4433 Interpoint Bivd. 
Dayton 45424 

Tel: (513) 236-9900 
TWX: 810-459-1622 


tPioneer/Cleveland 
4800 E. 131st Street 
Cleveland 44105 
Tel: (216) 587-3600 
TWX: 810-422-2211 


OKLAHOMA 


tComponents Speciaities, Inc. 
7920 E. 40th Street 

Tulsa 74145 

Tel: (918) 664-2820 

TWX: 910-845-2215 ° 


OREGON 


tAimac/Stroum Electronics 
8022 S.W. Nimbus, Bidg. 7 
Beaverton 97005 

Tel: (503) 641-8070 

TWX: 910-467-8743 


tHamilton/ Avnet Electronics 
6024 S.W. Jean Rd. 

Bidg. C, Suite 10 

Lake Oswego 97034 

Tel: (503) 635-7848 

TWX: 910-455-8179 


PENNSYLVANIA 


Arrow Electronics 

650 Seco Rd. 
Monroeville, PA 15146 
Tel: (412) 856-7000 


tArrow Electronics 
650 Seco Rd. 
Monroeville 15146 
Tal: (412) 856-7000 


Pioneer / Pittsburgh 
259 Kappa Drive 
Pittsburgh 15238 
Tel: (412) 782-2300 
TWX: 710-795-3122 


Pioneer /Delaware Valley 
261 Gibralter Road 
Horsham 19044 

Tel: (215) 674-4000 
TWX: 510-665-6778 


TEXAS 


Arrow Electronics 
13715 Gama Road 
Dallas 75234 

Tel: (214) 386-7500 
TWX: 910-860-5377 


Arrow Electronics, Inc. 

10700 Corporate Drive, Suite 100 
Stafford 77477 

Tel: (713) 491-4100 

TWX: 910-880-4439 


Component Specialties, inc. 
8222 Jamestown Drive 
Suite 115 

Austin 78758 

Tel: (512) 837-8922 

TWX: 910-874-1320 


tComponent Specialties, Inc. 
10907 Shady Trail, Suite 101 
Dallas 75220 

Tel: (214) 357-6511 

TWX: 910-861-4999 


tComponent Specialties, inc. 

8181 Commerce Park Drive, Suite 700 
Houston 77036 

Tel: (713) 771-7237 

TWX: 910-881-2422 


Hamilton/ Avnet Electronics 
10508A Boyer Bivd. 

Austin 78757 

Tel: (612) 837-8911 

TWX: 910-874-1319 


tHamilton/ Avnet Electronics 
2111 W. Walnut Hill Lane 
Iving 75062 

Tel: (214) 659-4100 

TWX: 910-860-5929 


tHamilton/ Avnet Electronics 
3939 Ann Arbor Drive 
Houston 77063 

Tel: (713) 780-1771 

TWX: 910-881-5523 


UTAH 


tHamilton/ Avnet Electronics 
1585 West 2100 South 

Salt Lake City 84119 

Tel: (801) 972-2800 

TWX: 910-925-4018 


WASHINGTON 


tAlmac /Stroum Electronics 
5811 Sixth Ave. South 
Seattle 98108 

Tel: (206) 763-2300 

TWX: 910-444-2067 


tHamilton/ Avnet Electronics 
14212 N.E. 21st Street 
Bellevue 98005 

Tel: (206) 453-5844 

TWX: 910-443-2469 


TWyle Distribution Group 
1750 132nd Avenue N.E. 
Believue 98005 

Tal: (206) 453-8300 
TWX: 910-443-2526 


WISCONSIN 


tArrow Electronics 

430 W. Rausson Avenue 
Oakcreek 53154 

Tel: (414) 764-6600 
TWX: 910-262-1193 


tHamilton/ Avnet Electronics 
2975 Moorland Road 

New Berlin 53151 

Tel: (414) 784-4510 

TWX: 910-262-1182 


CANADA 


ALBERTA 


+L.A. Varah Ltd. 
4742 14th Street N.E. 
Calgary T2D 6L7 

Tal: (403) 230-1235 
TWX: 038-258-97 


Zentronics 

9224 27th Avenue 
Edmonton T6N 1B2 
Tel: (403) 463-3014 
Telex: 03742841 


Zentronics 

3651 21st N.E. 
Calgary T2E 6T5 
Tel: (403) 230-1422 


BRITISH COLUMBIA 


tL.A. Varah Ltd. 

2077 Alberta Street 
Vancouver V5Y 1C4 
Tel: (604) 873-3211 
TWX: 6 10-929- 1068 


Zentronics 

550 Cambie St. 
Vancouver V6B 2N7 
Tel: (604) 688-2533 
TWX: 04-5077-89 


MANITOBA 


L.A. Varah 5 
1- 1832 King Edward Street 
Winnipeg R2R ON1 

Tal: (204) 633-6190 

TWX: 07-55-365 


Zentronics 

590 Berry St. 
Winnipeg R3H 0S 1 
Tel: (204) 775-8661 


NOVA SCOTIA 


Zentronics 
30 Simmonds Dr., Unit B 
Dartmouth, B3B 1R3 
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ONTARIO 


tHamilton / Avnet Electronics 
6846 Rexwood Road, Units G & H 
Mississauga L4V 1M5 

Tel: (416) 677-4732 

TWX: 610-492-8867 


tHamilton/ Avnet Electronics 
1736 Courtwood Cresent 
Ottawa K2C 3J2 

Tel: (613) 226-1700 

TWX: 053-4971 


tL.A. Varah, Ltd. 
505 Kenora Avenue 
Hamilton L8E 3P2 
Tel: (416) 561-9311 
TWX: 061-8349 


tZentronics 

141 Catherine Street 
Ottawa K2P 103 
Tel: (613) 238-6411 
TWX: 053-3636 


tZentronics 

8 Kilbury Ct. 
Brampton, Ontario 
Toronto, L6T 374 
Tel: (416) 451-9600 
Telex: 06-976-78 


Zentronics 

564/10 Weber St., N. 
Waterloo, NAL 5C6 
Tel: (519) 884-5700 


QUEBEC 


tHamilton/ Avnet Electronics 
2670 Sabourin Street 

St. Laurent H4S 1M2 

Tel: (514) 331-6643 

TWX: 610-421-3731 


Zentronics 

5010 Rue Pare Street 
Montreal H4P 1P3 
Tel: (514) 735-5361 
TWX: 05-827-535 


{Microcomputer System Technical Demonstrator Centers 


3065 Bowers Avenue 

Santa Ciara, California 95051 
Tel: (408) 987-8080 ..~ 
TWX: 910-338-0026 

TELEX: 34-6372 


CALIFORNIA 


Intel Corp. . 

1601 Old Bayshore Hwy. 
Suite 345 aes 
Burlingame 94010 

Tel: (415) 692-4762 

TWX: 910-375-3310 


Intel Corp. 

2000 E. 4th Street 
Suite 110 

Santa Ana 92705 
Tel: (714) 835-2670 
TWX: 910-595-2475 


Intel Corp. 

7670 Opportunity Road 
San Diego 92111 

Tel: (714) 268-3563 


Intel Corp. 

5530 N. Corbin Ave. 
Suite 120 

Tarzana 91366 

Tel: (213) 708-0333 


COLORADO 


Intel Corp. 

650 South Cherry 
Suite 720 

Denver 80222 

Tel: (303) 321-8086 
TWX: 910-931-2289 


CONNECTICUT 


Intel Corp. 

36 Padanaram Rd. 
Danbury, CT 06810 
Tel: (203) 792-8366 


FLORIDA 


Intel Corp. 

1500 N.W. 62nd Street 
Suite 104 

Ft. Lauderdale 33309 
Tel: (305) 771-0600 
TWX: 510-956-9407 


Intel Corp. 

500 N. Maitiand Ave. 
Suite 205 

Maitland, FL 32761 
Tel: (305) 628-2393 
TWX: 810-853-9219 


Intel Corp. 

5151 Adanson St. 
Orlando 32804 

Tel: (305) 628-2393 


GEORGIA 


Intel Corp. 

3300 Holcomb Bridge Rd. #225 
Norcross, GA 30092 

Tel: (404) 449-0541 


ILLINOIS 


intel Corp. 

2550 Golf Road 

Suite 815 

Rolling Meadows 60008 
Tel: (312) 981-7230 
TWX: 910-253-1825 


KANSAS 


Intel Corp. 

9393 W. 110th Street 
Suite 265 

Overland Park 66210 
Tel: (913) 642-8080 


MARYLAND 


Intel Corp. 

7257 Parkway Drive 
Hanover 21076 

Tel: (301) 796-7500 
TWX: 710-862-1944 


’ MASSACHUSETTS 


Intel Corp. 
27 industrial Avenue 


‘Chelmsford 01824 


Tel: (617) 256-1800 
TWX: 710-343-6333 


‘MICHIGAN 


‘. {ntel Corp. 
- 26600 Northwestern Hwy. 


Suite 401 


"Southfield 48075 


Tel: (313) 353-0920 
TWX: 810-244-4915 


MINNESOTA 


' Intel Corp. 
‘7401 Metro Bivd. 
' Suite 355 
‘Edina 55435 
- Tel: (612) 835-6722 


TWX: 910-576-2867 


MISSOURI 
intel Corp. 


-§02 Earth City Plaza 
. Suite 121 
- Earth City 63045 


Tel: (314) 291-1990 
NEW JERSEY 


~ Intel Corp. 


2460 Lemoine Avenue 
1st Floor 

Ft. Lee 07024 

Tel: (201) 947-6267 
TWX: 710-99 1-8693 


‘NEW YORK 
‘Intel Corp. 


2255 Lyell Avenue 


‘Rochester, NY 14606 


Tel: (716) 264-6120 


‘NORTH CAROLINA 


Intel Corp. 

2306 W. Meadowview Rd. 
Suite 206 

Greensboro, NC 27407 
Tel: (919) 294-1541 


OHIO 
Intel Corp. 


Chagrin-Brainard Bidg. Suite 300 | 


28001 Chagrin Bivd. 
Cleveland 44122 
Tal: (216) 464-2736 
TWX: 810-427-9298 
Intel Corp. 

6500 Poe Avenue 
Dayton 45414 

Tel: (513) 890-5350 
TWX: 810-450-2528 


OREGON 
Intel Corp. 


10700 S.W. Beaverton-Hilisdale Hwy. _ 


Suite 22 

Beaverton 97005 
Tel: (503) 64 1-8086 
TWX: 910-467-8741 


PENNSYLVANIA 


Intei Corp. 

§00 Pennsyivania Avenue . 
Fort Washington 19034 
Tel: (215) 641-1000 

TWX: 510-661-2077 


Intel Corp. 

201 Penn Center Blvd. 
Suite 301 W. 
Pittsburgh, PA 15235 
Tel: (412) 823-4970 


U.S. AND CANADIAN SERVICE OFFICES 


’ TEXAS 


-* Intel Corp. BG 
'°313 E. AndersonLane’' =. °:: 
- Suite 314 
» Austin 78752 
Tel: (512) 454-8477 


TWX: 910-874-1347 | 


Intel Corp. 

2925 L.B.J. Freeway 
Suite 175 

Dallas 75234 


- + Tel: (214) 241-2820 
- TWX: 910-860-5617 


Intel Corp. 

6420 Richmond Avenue 
Suite 280 : 
Houston 77057 

Tel: (713) 784-1300 


"TWX: 910-881-2490 


VIRGINIA 


Intel Corp. 
7700 Leesburg Pike 


' Suite 412 
' + Falls Church 22043 
‘: Tel: (703) 734-9707 


TWX: 710-931-0625 


_ WASHINGTON ‘ 


' ~ Intel Corp. 
. 1603 116th Ave. N.E. 


Suite 114 
Bellevue 98005 


Tel: (206) 232-7823 
" TWX: 910-443-3002 


: WISCONSIN 


Intel Corp. 

150 S. Sunnyslope Road 
Suite 148 

Brookfield 53005 

Tel: (414) 784-9060 


CANADA 


Intel Corp. 
50 Galaxy Bivd. 
Unit 12 


: Rexdale, Ontario 


M9W4Y5 
Tel: (416) 675-2105 


Telex: 069-89278 


Intel Corp. 
39 Bells Corners 


. Ottawa, Ontario 


K2H 8R2 
Tel: (613) 829-9714 


"Telex: 053-4115 _. 
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INTERNATIONAL SALES AND MARKETING OFFICES 


3065 Bowers Avenue 

Santa Clara, California 95051 
Tel: (408) 987-8080 

TWX: 910-338-0026 

TELEX: 34-6372 


INTERNATIONAL DISTRIBUTORS/ REPRESENTATIVES 


AUSTRALIA 


A.J.F. Systems & Components Pty. Ltd. 
310 Queen Street 

Melbourne 

Victoria 3000 

Tel: 679-702 

TELEX: AA 31261 


Warburton Franki 

Corporate Headquarters 

372 Eastern Valley Way 
Chatswood, New South Wales 2067 
Tel: 407-3261 

TELEX: AA 21299 


AUSTRIA 


Bacher Elektronische Geraete GmbH 
Rotenmulgasse 26 

A 1120 Vienna 

Tel: (222) 835646 

TELEX: 131532 


Rekirsch Elektronik Geraete GmbH 
Lichtensteinstrasse 97 16 

A 1090 Vienna 

Tal: (222) 347646 

TELEX: 134759 


BELGIUM 


Inelco Belgium S.A. 

Ave. des Croix de Guerre 94 
B1120 Brussels 

Tel: (02) 216 01 60 

TELEX: 25441 


BRAZIL 


lcotron S.A. 

0511 Av. Mutinga 3650 

6 Andar 

Pirituba Sao Paulo 

Tel: 261-0211 

TELEX: 1122274/ICOTBR 


CHILE 


DIN 

Av. Vic. MacKenna 204 
Casilla 6055 

Santiago 

Tel: 227 564 

TELEX: 3520003 


CHINA 


C.M. Technologies 
525 University Avenue 
Suite A-40 

Palo Alto, CA 94301 
Tel: (415) 326-9150 


Schmidt & Co. Ltd. 

Wing On Centre, 28th Floor 
Connaught Road 

Hong Kong 

Tel: 011-852-5-455-644 
TELEX: 74766 SCHMC HX 


COLOMBIA 


International Computer Machines 
Carrera 7 No. 72-34 

Apdo. Aereo 19403 

Bogota 1 

Tel: 211-7282 

TELEX: 44495 TOYOCO 


CYPRUS 


Cyprus Eltrom Electronics 
P.O. Box 5393 

Nicosia 

Tel: 21-27982 


DENMARK 


ITT Multi Komponent 
Fabrysparken 31 
DK-2600 Gloskrup 
Tel: (02) 45 66 45 
TX: 33355 


Scandinavian Semiconductor 
Supply A/S 

Nannasgade 18 

DK-2200 Copenhagen 

Tel: (01) 83 50 90 

TELEX: 19037 


FINLAND 


Oy Fintronic AB 
Melkonkatu 24 A 
SF-002 10 

Helsinki 21 

Tel: (0) 682 60 22 
TELEX: 124 224 Ftron SF 


FRANCE 


Celdis S.A.° 

53, Rue Charlies Frerot 
F-94250 Gentilly 

Tel: (01) 546 13 13 
TELEX: 200 485 


Feutrier 

Rue des Trois Glorieuses 
F-42270 St. Priest-en-Jarez 
Tel: 33 (77) 74 67 33 
TELEX: 300 0 21 


Metrologie° 

La Tour d’ Asnieres 

1, Avenue Laurent Cely 
92606-Asnieres 

Tel: (1) 791 44 44 
TELEX: 611 448 


Tekelec Airtronic* 
Cite des Bruyeres 
Rue Carle Vernet 
F-92310 Sevres 
Tel: (01) 534 75 35 
TELEX: 204552 


GERMANY 


Electronic 2000 Vertriebs GmbH 
Neumarkter Strasse 75 

D-8000 Munich 80 

Tel: (89) 43 40 61 

TELEX: 522561 


Jermyn GmbH 
Postfach 1180 
Schulstrasse 48 
D-6277 Camberg 
Tel: (6343) 4231 
TELEX: 484426 


Kontron Elektronik GmbH 
Breslauerstrasse 2 

8057 Eching B 

D-8000 Munich 

Tel: (89) 319 011 
TELEX: 522122 


Neye Enatechnik GmbH 
Schillerstrasse 14 

D-2085 Quickborn-Hamburg 
Tel: (4106) 6121 

TELEX: 213590 


GREECE 


American Technical Enterprises 
P.O. Box 156 

Athens 

Tel: 30-1-8811271 

TX: 30-1-8219470 


HONG KONG 


Schmidt & Co. 

Wing on Center, 28th Floor 
Connaught Road 

Hong Kong 

Tel: 5-455-644 

TELEX: 74766 Schmc Hx 


INDIA 
Micronic Devices 


104/109C, Nirmal Industrial Estate 


Sion (E) 

Bombay 400022, india 

Tel: 486-170 

TELEX: 011-5947 MDEV IN 


ISRAEL 


Eastronics Ltd.* 
11 Rozanis Street 
P.O. Box 39300 
Tel Aviv 61390 
Tel: (3) 47 51 51 
TELEX: 33638 


ITALY 


Eledra 3S S.P.A.° 
Viale Elvezia, 18 
| 20154 Milano 
Tel: (2) 34 97 51 
TELEX: 332332 


JAPAN 


Asahi Electronics Co. Ltd. 
KMM Bidg. Room 407 
2-14-1 Asano, Kokura 
Kita-Ku, Kitakyushu City 802 
Tel: (093) 511-6471 

TELEX: AECKY 7126-16 


Hamilton-Avnet Electronics Japan Ltd. 
YU and YOU Bidg. 1-4 Horidome-Cho 
Nihonbashi Chuo-Ku, Tokyo 103 

Tel: (03) 662-9911 

TELEX: 2523774 


Ryoyo Electric Corp. 


’ Konwa Bidg. 


1-12-22, Tsukiji 
Chuo-Ku, Tokyo 104 
Tel: (03) 543-7711 


Tokyo Electron Ltd. 

Shin Juku, Nomura Bidg. 
26-2 Nishi-Shin Juku-ichome 
Shin Juku-Ku, Tokyo 160 
Tel. (03) 343-4411 

TELEX: 232-2220 LABTEL J 


KOREA 


Koram Digital 

Room 909 Woonam Bldg. 
7, 1-KA Bongre-Dong 
Chung-Ku Seoul 

Tel: 238-123 

TELEX: K23542 HANSINT 


MEXICO 


Proveedora Electronica, S.A. (Proesa) 
Prol. Moctezuma Ote. 24 


‘ Col. Romero de Terreros 


Apdo. Postal 21-139 
Mexico 21, D.F. 

Tel: 554-8300 

TELEX: 017-72402 SAULME 


NETHERLANDS 


Ineico Nether. Comp. Sys. BV 
Turfstekerstraat 63 

P.O. Box 360 

NL Aalsmeer 1430 

Tel: (2977) 28855 

TELEX: 14693 


Koning & Hartman 
Koperwerf 30 

P.O. Box 43220 

2544 EN's Gravenhage 
Tel: 31 (70) 210.101 
TELEX: 31528 


NEW ZEALAND 


McLean Information Technology Ltd. 
P.O. Box 18-065 

Glenn Innes, Auckland, 6 

Tei: 587-037 

TELEX: NZ2763 KOSFY 


NORWAY 


Nordisk Elektronic (Norge) A/S 
Postoffice Box 122 
Smedsvingen 4 

1364 Hvalstad 

Tel: (2) 786 210 

TELEX: 16963 


PORTUGAL 


Ditram 

Componentes E Electronica LDA 
Av. Miguel Bombarda, 133 
P1000 Lisboa 

Tel: (19) 545 313 - 

TELEX: 14182 Brieks-P 


SINGAPORE. 


General Engineers Corporation Pte. Ltd. 


Bik 3, Units 1003-1008, 10th Floor 
P.S.A. Multi-Storey Complex 

Pasir Panjang Road 

Singapore 0511 

Tel: 271-3163 

TELEX: RS23987 GENERCO 
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SOUTH AFRICA 


Electronic Building Elements 
P.O. Box 4609 

Hazelwood, Pretoria 0001 
Tel: 01 1-27- 12-46-9221 
TELEX: 30181SA 


SPAIN 


interface S.A. 

Ronda San Pedro 22, 3° 
Barcelona 10 

Tal: (3) 301 78 51 

TWX: 51508 


ITT SESA 

Miguel Angel 16-6 
Madrid 10 

Tel: (1) 410.23.54 
TELEX: 27707/27461 


SWEDEN 


AB Gosta Backstrom 
Box 12009 
Aistrihercatan 22 

$- 10221 Stockholm 12 
Tel: (8) 541 080 
TELEX: 10135 


Nordisk Electronik AB 
Box 27301 

S- 10254 Stockholm 
Tel: (8) 635 040 
TELEX: 10547 


SWITZERLAND 


Industrade AG 
Gemsenstrasse 2 
Postcheck 80 - 21190 


‘CH-8021 Zurich 


Tel: (1) 363 22 30 
TELEX: 56788 


TAIWAN 


Taiwan Automation Co. * 
3d Floor #75, Section 4 
Nanking East Road 
Taipei 

Tel: 771-0940 

TELEX: 11942 TAIAUTO 


TURKEY 


Turkelek Electronics 
Apapurk Boulevard 169 
Ankara 

Tel: 189483 


UNITED KINGDOM 


Comway Microsystems Ltd. 
Market Street 
UK-Bracknell, Berkshire 
Tel: 44 (344) 51654 
TELEX: 847201 


M.E.D.L. 

East Lane Road 

North Wembley 

Middlesex HA9 7PP 

Tel: 44 (01) 904-9303/908-4111 
TELEX: 28817 


Jermyn Industries (Mogul) 
Vestry Estate 
Sevenoaks, Kent 

Tel: (0732) 501.44 
TELEX: 95142 


Rapid Recall, Ltd. 

Rapid House/Denmark St 
High Wycombe 

Bucks, England HP11 2ER 
Tel: 44 494 26 271 
TELEX: 849439 


Bytech Ltd. 

Sutton Park Avenue 
Reading, Berkshire 61A2 
Tel: (0734) 61 031 
TELEX: 848215 


*Field Application Location 


3065 Bowers Avenue 

Santa, Clara, California 95051 
Tel: (408) 987-8080. 
TWX: 910-338-0026 

TELEX: 34-6372 


INTEL® MARKETIN 


AUSTRALIA : 


intel Semiconductor Pty. Ltd. 
Suite 2, Level 15, North Point 
100 Miller Street me 4" 
North Sydney, NSW, 2060 ~ 
Tel: 450-847 

TELEX: AA 20097 


BELGIUM 


Intel Corporation S.A. 

Rue du Moulin a Papier 51 
Boite 1 

B-1160 Brussels 

Tel: (02) 660 30 10 
TELEX: 24814 


DENMARK 


Intel Denmark A/S° 
Lyngbyvej 32F 2nd Floor 
DK-2100 Copenhagen East 
Tel: (01) 18 20 00 ss 
TELEX: 19567 


FINLAND 


Intel Finland OY 
Sentnerikuja 3 

SF - 00400 Helsinki 40 
Tel: (0) 56244 55 
TELEX: 123 332 


FRANCE 


Intel Corporation, S.A.R.L.° 
5 Place de la Balance 

Silic 223 

_ 94528 Rungis Cedex 

Tel: (01) 687 22 21 
TELEX: 270475 


G OFFICES 


GERMANY 

Intel Semiconductor GmbH * 
Seidistrasse 27 “ 
D-8000 Muenchen 2 

Tel: (89) 53891 

TELEX: 523 177 


intel Semiconductor GmbH 


_ Mainzer Strasse 75 


D-6200 Wiesbaden 1 
Tel: (6121) 70 08 74 
TELEX: 04186183 


Intel Semiconductor GmbH 
Wernerstrasse 67 

-P.O. Box 1460 

.0-7012 Fellbach . 

Tel: (711) 58 00 82 


-, TELEX: 7254826 


intel Semiconductor GmbH 


‘““Hohenzollern Strasse 5:9 7 


3000 Hannover 1 
Tel: (611) 32 70 81 
TELEX: 923625 


Intel Semiconductor GmbH 
Vertriebsburo Dusseldorf 
Ober-Ratherstrasse 2 
4000 Dusseldorf 30 

Tel: (all) 65 10 54 

TELEX: 8586977 


HONG KONG 


Intel Semiconductor Ltd. 
99-105 Des Voeux Rd., Central 
18F, Unit B 

Hong Kong 

Tel: 5-450-847 


_, TELEX: 63869 
» ISRAEL 


intel Semiconductor Ltd. ° 
P.O. Box 1659 

Haifa 

Tel: 4/524 261 

TELEX: 46511 


ITALY 
“Intel Corporation Italia Spa 


Milanofiori, Palazzo E 
20094 Assago (Milano) 


~ Tel: (02) 824 00 06 


TELEX: 315183 INTMIL 


; JAPAN 


-- Intel Japan K.K.° 
‘Flower Hill-Shinmachi East Bldg. 


1-23-9 Shinmachi, Setagaya-ku 
Tokyo 154 


_, Tel: (03) 426-9261 


TELEX: 781-28426 
NETHERLANDS 


~”. Intel Semiconductor.Nederland B.V. 


Oranjestraat 1 

3441 Ax Woerden 
Netherlands 

Tel: 31-3480- 112-64 
TELEX: 47970 


- Intel Semiconductor B.V. 


Cometongebouw 


- Westblaak 106 


3012 Km Rotterdam 


. Tel: (10) 149122 


TELEX: 22283 


_ NORWAY 
_ Intel Norway A/S 


P.O. Box 92 
Hvamveien 4 
N-2013 
Skjetten 

Tel: (2) 742 420 
TELEX: 18018 


INTERNATIONAL SALES AND MARKETING OFFICES 
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“SWEDEN 


Intel Sweden’A.B.* 
Box 20092 


’ Enighetsvagen 5 
- §-16120 Bromma 


Tel: (08) 98 53 85 
TELEX: 12261 


“SWITZERLAND 


Intel Semiconductor A.G.. 
Forchstrasse 95 : 

CH 8032 Zurich 

Tel: (01) 55 45 02 
TELEX: 557 89 ich ch 


UNITED KINGDOM 


Intel Corporation (U.K.) Ltd. ° 

5 Hospital Street 

Nantwich, Cheshire CWS 5RE © 
Tel: (0270) 626 560 


‘TELEX: 36620 


Intel Corporation (U.K.) Ltd. 
Dorcan House 
Eidene Drive 


' Swindon, Wiltshire SN3 310 
_ - Tel: (0793) 26 101 
_ TELEX: 444447 INT SWN 


*Field Application Location 


in 


Intel Corporation © 
3065 Bowers Avenue 
Santa Clara, CA 950517 


Intel International 
Rue du Moulin a Papier 57, Boite 1, 
B-1160 Brussels, Belgium 


Intel Japan K.K. 
Flower Hill-Shinmachi East Bldg. 
1-23-9, Shinmachi, Setagayu-ku 
Tokyo 154, Japan 
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